Show page source of FileRelease_Guide #105406

[[PageNavi(NavigationList)]]

= File Release Guide

By using OSDN's file release function, you can distribute softwares created by your project.

== File release related terms

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.


{{{
Package
  |
  +---Release
  |   :
  |   :
  +---Release
       |
       +---File
       |   :
       |   :
       +---File
}}}

=== Package

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”.

=== Release

Each package can have multiple releases.

Release comprises the followings.

  * File (or files)
  * Release Notes (can be written in multiple languages)
  * Change Log (can be written in multiple languages)

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.


== How to release

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.

 1. Create a package.
 2. Create a release. (File upload)



=== 1. Create a package

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.)


=== 2  Create a release

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 name
 * Open range
 * Release notes
 * !ChangeLog
 * Files included in the release

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.


== About open range

For each package/release/file, you can set up “open range” individually.

 * '''Public''': Anyone can access (and this is generally selected.)
 * '''Hidden''': Will not be displayed in the list (except when viewed by the project admin/file release admin). However, anyone with the knowledge of URL to access can access directly. This is a kind of set up you would want to use, for example, when you provide the project members with the URL, so that they can check for any mistakes before making it public.
 * '''Private''': Only project admin/file release admin can view. (Even with the knowledge of the URL, anyone without the authority can not view.)

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.


== Preferred Download

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.

== System Requirements

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).

== Release File URL Formats

URLs that specify packages, releases, and release files will be expressed as below.

 * Package URL: !https://osdn.jp/projects/(Project Name)/releases/(Package id)
 * Release URL: !https://osdn.jp/projects/(Project Name)/releases/(Release id) 
 * Release File URL: !https://osdn.jp/projects/(Project Name)/downloads/(Release id)/(File Name)/

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.

 * Simplified Release-File URL: !https://osdn.jp/dl/(Project Name)/(File Name)

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.

 * Release URL: https://osdn.jp/projects/ttssh2/releases/64798
 * Download URL of exe file: https://osdn.jp/projects/ttssh2/downloads/64798/teraterm-4.90.exe/
 * Simplified URL of exe file: https://osdn.jp/dl/ttssh2/teraterm-4.90.exe


== Direct Download

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.


== Upload a File Release without Using Web UI

You can use OSDN's [/projects/osdn-codes/wiki/APIGuide 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 [/projects/osdn-codes/wiki/CommandLineInterface 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.


[[PageNavi(NavigationList)]]