Description of the file storage feature which supports uploading via general-purpose command line tools, like rsync, is on the next page. It is a different feature from the package-style release feature which will be described here on this page.
By using OSDN's file release function, you can distribute softwares created by your project.
OSDN's file release system is managed in a layered structure, as it's shown below. First, we'll talk about each of these terms.
OSDN Docs (English)
編集Package
|
+---Release
| :
| :
+---Release
|
+---File
| :
| :
+---File
Package is the largest unit for file release, and often, it is given the name of the software. Because there are many projects giving the same name for the software and project, as default, we provide each project with a package that has the project's UNIX name. (You can certainly change the name if you want to.)
A project can have multiple packages. For example, let's say there's a project called “foo” which develops not only a software called “foo”, but also a software called “bar”. In that case, it would be convenient to create packages called “foo” and “bar”.
Each package can have multiple releases.
Release comprises the followings.
In short, release is a collection of all the related files that are to be actually distributed.
For example, let's say you want to release version 0.1 for a program called foo. In that case, you will create release “0.1” under the package “foo”. Then, You will upload the file for the actual program, foo version 0.1. You would also want to write a release notes (about things like “The first release” or “Still the alpha version”), and add to the change log with the things have been changed since the last release.
The releases that have been created will be displayed in a list which allows general users to download from there.
Conducting a file release is limited to the users with permission, such as project admins and release admins.
The procedure for file release is as follows.
Once a project has been registered, a package will be automatically created, and it will be named the same as the project's UNIX name. If you're okay with the name, then you don't have to create a new package. You may move on to the next step.
To create a Package, find "Add Package" button from the release list or the admin page for the downloads, and click. Enter the package name, then select the open/closed status. Generally, it should be fine with "open". (We'll elaborate on the status later in the chapter.)
Once you've created a package, you can add releases to that package. Find the “Add Release” button from the release list or the admin page for the downloads, and click.
For a release, you can set up the following items of information.
Release notes and ChangeLog can be written in multiple languages.
For each release, you can add multiple files. And for each of those files, you can also set up the open range.
From browsers (that support uploading multiple files), you can upload multiple files simultaneously.
You could also use FTP for uploading files. When using FTP for uploads, make sure the switch for FTP uploading is turned on. Information regarding FTP uploading will be displayed.
For each file upload, the file size is limited to 4.7GB.
For each release, you can attach “release note” and “change log” documents. To attach documents, choose the methods you like from the following options.
When the system recognizes files, from among the uploaded files, that match the conditions, the names of those files will appear on editing UI for the release. To show the contents of the files, select the files from there (Please note, it will not be updated without your consent to apply). In addition, please note that after the applying process, all the document information that was entered in the entering form will be deleted.
For each package/release/file, you can set up "open range" individually.
You can set up public/private status for each package/release/file, but an actual status will be affected by its higher rank. (If you're talking about a release, then it will be influenced by the package, and if it's a file that you're talking about, then it will be influenced by the release and package that includes that file.)
For example, let's say the status for a release is set to public, but the package that includes that release is set to hidden, then that release will not appear in the list.
You can also set up preferred download to make a file displayed with priority in places like file release list, project top page, and so on. For example, by specifying a file to be the stable version, you can make it appear in a way that stands out among other files, and that way, you can get the users to download that file with priority.
You can specify one preferred download for each file type.
You can edit the system requirement in which you can write about the operation conditions of the program you have released. For each project as a whole, you can edit the system requirements (in multiple languages).
URLs that specify packages, releases, and release files will be expressed as below.
When leading users from project web to download page, they will be notified by a release or with release-file URL format shown above. There are some URL formats that specify a mirror server, but historically speaking those URLs don't have the permanence, so you are recommended to hold back on using them. By the way, package id and release id are just a line of numbers, and that may cause inconvenience when a project is trying to notify a download URL. For that reason, there's a simplified URL format as shown below that specifies a package/release/release file.
At times, files with a same name could coexist in a project, and in such cases, when that package/release/file name is using the above format, this will become an URL that designates the newer one.
Also regarding releases, there may be cases where multiple packages share a same name. For example let's say a project have package A and B and both contain release 1.0. On such case, by specifying the package name, you can clarify which release for which package.
Given TeraTerm 4.90 as an example, you can use URLs like the ones below for public announcements. Use them accordingly.
Currently, when a release-file URL is accessed from wget, curl, libwww-perl, PowerShell, apt, dnf, or other package management tools, downloading of the file will begin right away without having to go via html page.
You can use OSDN's REST API to upload and edit file releases. We are also equipped with command line tools that were implemented through the use of this API. By using the command-line tools, you can reflect file tree of the local side to the release-file tree of the OSDN side, easily with a simple command.
By using VirusTotal, uploaded files will be scanned for viruses.
[ページ情報]
更新日時: 2020-04-25 01:36:37, 更新者: sado
[ライセンス]
GNU Free Documentation License
[権限]
表示:無制限, 編集:メンバー, 削除/設定:メンバー