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)
editPackage
|
+---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 people with the authority, such as project admins and users with the authority of a release admin.
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 another 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 range. Generally, it should be fine with “public”. (We'll elaborate on the open range 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 2GB.
For each package/release/file, you can set up “open range” individually.
You can set up the open range for each package/release/file, but each of the actual open range will be affected by its higher rank. (If you're talking about a release, then it will be under the influence of the package, and if it's a file that you're talking about, then it will be under the influence of the release and package that includes that file.)
For example, let's say the open range for a release was set to public. But if the the package was 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 displayed 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 condition 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 release file.
At times, files with a same name could coexist in a project, and in such cases, when that file name is using the above format, this will become an URL that designates the latter one.
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, or PowerShell, 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.