Submit new documentation | View Documentation | Admin | Search Site Docs
This document provides a comprehensive guide to the File Release System (FRS), which helps projects to distribute their files through the use of the high-capacity SourceForge.net download server network.
This document has been
designed for use solely by registered SourceForge.net users
who are listed as an administrator on a project hosted on
SourceForge.net (i.e. active developers on a project who are
listed in the "Project Admins" section of the Summary Page
for that project). The information provided here assumes you
are a project administrator, affiliated with a project and
listed as a project administrator (not just a developer). If
you are not a project administrator, the information in this
document likely does not apply to you directly; though you
do not have the security (as a non-admin) to use the
instructions provided here, it may be good background
information none-the-less.
Table of Contents » |
doc feedback |
support
- What is the file release system (FRS)?
- How can I download file releases from a project?
- How often should I release files from my project?
- Overview: Projects, packages, releases and files
- What steps are involved in releasing files on SourceForge.net?
- How soon after I make a file release will it show on my project download page?
- Where is the File Release System interface located?
- How do I create a package under the file release system?
- How do I upload a file to include in a file release?
- How do I remove a file from the incoming directory on upload.sourceforge.net?
- How do I create a new file release under the file release system?
- Shadowing the actions of your end-users: testing your releases
- How much disk space do I get for storing my file releases?
- How can I see how many people have downloaded one of my released files?
- What should I include as file releases?
- What types of materials should I NOT include in my project file releases?
- How can I include in my project's file releases those materials which we released before moving to SourceForge.net?
- How does the file release system relate to project CVS services?
- How can I change the details of an existing file release?
- How can I remove an unwanted file release from the file release system?
- How can I remove an unwanted package from the file release system?
- Should I remove older file releases to save you space?
- How can I let another member of my team perform file releases?
- I am a project administrator and it seems like I don't have sufficient permissions to perform a file release; how can I fix this?
- Organizing and Managing your SourceForge.net Resources as Related to your File Releases
- May I upload my file releases using SSH, SCP or SFTP?
- Why doesn't my SourceForge.net username and password work on the upload.sourceforge.net server?
- Download server details
- Where can I obtain support for the file release system?
^ What is
the file release system (FRS)? » |
doc feedback |
support
One of the cornerstones of Open Source software development is the distribution of that software. The SourceForge.net file release system (FRS) provides a mechanism for SourceForge.net-hosted projects to post files to our network of high-capacity download servers. The file release system is used by project administrators (and file release technicians) to post content to the download servers. Once content has been posted using the file release system, it becomes available for download by the general public and is stored on our high-capacity download servers.
^ How can I download file releases from a
project? » |
doc feedback |
support
SourceForge.net hosts a large number of Open Source software development projects. Each of the projects hosted on SourceForge.net has a summary page. The summary page for projects is often linked to on project web sites and is often listed in the Freshmeat.net entries for hosted projects. If you have not already found the summary page for the pertinent project, please make use of the search feature, found in the left navbar of the SourceForge.net site.
Once you reach the summary page for a project, you will notice a page section titled "Latest file releases". Make use of the "View ALL Project Files" link to display the list of available files to download. Locate the file you wish to download and make use of the filename link for that file. You will note that each file has a basic type description, date stamp, and size (so you know how much data you will be downloading before you start the download).
If you wish to review the release notes and change log (often included by project administrators so you will have an idea of what to expect from a release) for the file release you intend to download, simply make use of the link titled with the release name. Each file release is listed separately under a heading for its associated package. In the event that you locate a package which contains no releases, or a release which contains no files, please notify the project administrator for that project, so as that they may take steps to correct this.
Sample file release page: junit
^ How often
should I release files from my project? » |
doc feedback |
support
Release early, release often; the mantra of Open Source software developers everywhere. SourceForge.net hosts a variety of software development projects, in varying states of development and code maturity. It is entirely up to the project administrator of each project to decide when it is time to first release their software through the file release system, and how often subsequent releases should occur. We encourage every project to release their code publically early; this helps to spark interest in others, as well as to show growth in the project.
^ Overview: Projects, packages, releases and
files » |
doc feedback |
support
There are four basic components which play in to the file release system. SourceForge.net provides hosting for a number of Open Source software development projects. Each of these projects has their own space on SourceForge.net. File releases on the download servers are separated on per project basis. A file release made through the admin pages of a project will only show on the download page for that project
This overview will contain a description of how a fictional project, "widget", might use the SourceForge.net file release system. Several different scenarios will be provided during the course of this overview; the way your project decides to use SourceForge.net file release system will likely be similar to one of these descriptions.
When a project is working on a particular piece of software, that software is often referred to as a package. Freshmeat.net, a common source for file release news in the Open Source software community, is one such place where things are detailed on a per-package basis.
Example: the widget project developers are working on a new system for modelling the shapes of plastic boxes for use in a CADD/CAM system (which would manufacture these boxes). The widget project team is releasing this software under the package name "boxmodel". The package name need not differ from the UNIX name for your project; most commonly, packages are named after the project name (or vice versa). This choice is left to the project administrator. Samples:
Case: Project name differs from package name
Project name: alexandria
Package name: sourceforgeCase: Project name is the same as the package name
Project name: junit
Package name: junitWithin each file release system package will be one or more file releases. When a new instance of the package is released, a new file release is added within that package in the file release system. In our example, the widget project team has released version 1.2 of the boxmodel package, thus they have created a file release named "1.2" within the boxmodel package.
File releases may be named in a free-form manner on SourceForge.net. Open Source software projects often use different naming schemes; some projects use numerical releases (examples: 1.0, 3.1), some use a more hierarchical numerical release scheme (examples: 1.0.2, 2.0.2.3), and some even use code names for their releases (examples: Woody, Cartman). SourceForge.net permits you to name your releases as you desire; simply name your file releases accordingly in the file release system.
The substance of a file release is the file or files assigned to that release. Files assigned to a release are shown under that release when viewing the download page for a project. In order to assign a file to a file release, those files must first be uploaded to the incoming directory on upload.sourceforge.net. Once the file or files have been uploaded, the file release system interface is used to assign those files to a particular file release.
Most commonly, files are named with some bearing on the file package and file release they are going to be attached to. Within our example, the widget project has just released version 1.2 of the boxmodel package. They have built a gzipped tarball of sources and have named that file boxmodel-1.2.tar.gz. This file is then uploaded per the provided instructions, and attached to the "1.2" file release of the "boxmodel" package.
What happens when they release version 1.3 of boxmodel? When the new version of boxmodel is released, the widget project administrator simply adds the "1.3" file release to the "boxmodel" package, uploads the "boxmodel-1.3.tar.gz" source archive, and associates that file with the 1.3 release.
What happens if you want to include binaries as well as sources? The widget project administrator has started building RPMs for boxmodel. For each new file release, the project administrator now uploads three files: the .tar.gz source archive, a SRPM, and an i386 RPM. The SourceForge.net system permits you to associate multiple files with a single file release; files are differentiated by their naming and by the file type information added by the project administrator when the files are associated with the file release. The same process would be used for any other files related to a particular file release: binaries for other OS platforms or hardware architectures, documentation and manuals which would might be provided separately from the source archive as a convenience, etc.
Some projects have both a stable branch and a development or unstable branch. This permits end-users to choose between stability or the availability of cutting-edge features as they see fit. The best way to accommodate such a scheme under the SourceForge.net file release system is to have a separate package for the development releases from that used for the stable releases. To extend our example, the widget project decides to provide a separate development tree for their boxmodel code base. To facilitate this change, they create a new package named "boxmodel-devel". File releases under the development tree may then be added to the "boxmodel-devel" package and they may continue to post stable releases under the "boxmodel" package.
There may be cases where a project would need to include several different component packages for each release. Often times, these components are dependent on a base package, but are optional from the end-user perspective. A perfectly good solution is to include each of these components as a separate file within a particular file release.
What if our project releases multiple, very different, pieces of software? The way to deal with this case may differ from project to project. One way of dealing with this case would be to simply add another package for each of the major pieces of software the project provides. When the software has matured to the point where it generally is managed and developed by two separate development teams, the administrator for that project may decide to register a new, separate project to more cleanly separate the different package offerings. Generally speaking, adding a new package will usually suffice.
How can I convey information about file release changes or release notes to my end-users? When a file release is created, the administrator may elect to provide release notes and/or a change log for that release. A link to this information is displayed along side the download link for that release on the download page for the project. Release notes and change log information may, of course, also be included within the files included in the release.
This concludes our overview of the SourceForge.net file release system and its components. In summary, each software effort should have a project; each project should release one or more packages (the fewer packages, the better, generally); each package will contain one or more file release (and this number will increase as the project makes more software releases; and each file release will contain one or more file. To keep your administrative overhead low: keep things simple, allocate only what you need.
^ What steps are involved in releasing files on
SourceForge.net? » |
doc feedback |
support
- Login to SourceForge.net.
- Register your project on SourceForge.net, if you have not already done so.
- Access the File Release System interface.
- Create a package which will contain releases of this software, if you have not already done so.
- Upload the file(s) which will be associated with this file release.
- Create a file release within that package, for this specific release and attach the file(s) you uploaded to that file release.
- Shadow your end-user: download your released files and verify their integrity; walk through an install to verify proper, expected operation.
^ How soon after
I make a file release will it show on my project download
page? » |
doc feedback |
support
Updates to project download pages are currently performed on a 30 minute cycle. While changes and additions to your file releases will be reflected immediately in the admin interface for the file release system, it may take up to 30 minutes for your changes to be reflected on the download page for your project.
^ Where is the File Release System interface
located? » |
doc feedback |
support
The File Release System interface may be accessed from the Project Admin page for each project. As the administrator for a project, you may access the Project Admin interface for your project by using the "Project Admin" link in the left navbar of the SourceForge.net. Once you are viewing the Project Admin page for your project, use the "File Releases" link (near the top of the page) to access the File Release System interface.
^ How do I create a package under the file release
system? » |
doc feedback |
support
To create a package within the file release system, first access the file release interface. Enter the desired name for your package in the "New Package Name" field, then make use of the "Create This Package" button.
^ How
do I upload a file to include in a file
release? » |
doc feedback |
support
To release a file, generate a zip archive or tarball and place it at the root of your hard drive, for easy access. Then follow these instructions to perform the upload:
- FTP to upload.sourceforge.net
- Login as "anonymous"
- Use your e-mail address as the password for this login
- Set your client to binary mode ("bin" on command-line clients)
- Change your current directory to /incoming ("cd /incoming")
- Upload the desired files for the release ("put filename")
^ How do I remove a file from the incoming
directory on upload.sourceforge.net? » |
doc feedback |
support
In the event that you should upload the wrong file to the incoming directory on upload.sourceforge.net, you will probably be looking for a way to remove that file. It is important to realize that access to files in the incoming directory is restricted; in order for a file to be accessed remotely, it would need to be associated with a file release.
There are two solutions available for removing content from the incoming directory. First, the incoming directory is automatically purged every 24 hours (only materials which are more than 24 hours old and have not been attached to a file release are purged). If you cannot wait, you have the second option of attaching the bad upload to your file release, then deleting the file from the file release; it is important that you not do this on files you intend to overwrite (i.e. that you intend to replace with a file of the same file name).
^ How do I create a new file release under the file
release system? »
|
doc feedback |
support
To create a new file release, first access the file release interface. Second, make use of the "Add Release" link next to the package within which you wish to add a release. Enter the desired name for this release within the "New release name" field. Ensure that the "Of which package" option is set with the correct package name. It should be noted that once a package is created, it CANNOT be removed from the file release system; please check your selections at this time. Once you are comfortable that the file release name and package name appear correctly, make use of the "Create This Release" button.
Complete the details within the "Step 1" section of the resulting page. The release date should be set to the current date (unless you have suitable reason otherwise). The "Status" field should be set to "Active". Add change log and release notes details as desired. This data may be edited later if you make a mistake. Once you have checked the information you have added to this form, make use of the "Submit/Refresh" button at the bottom of the "Step 1" section of this page.
The resulting page will include a file listing, within the "Step 2" section of the page, which contains all files that have been uploaded to the incoming directory on upload.sourceforge.net, but have not yet been attached to a file release. If you have not already uploaded the files you intend to attach to this file release, please do so at this time (then make use of the "Refresh View" button in this page section).
Ensure that the check boxes for the files you wish to associate with this release are checked. Please double-check to verify that you have not selected the check boxes next to files uploaded by other users. Once you have confirmed your selections, make use of the "Add Files and/or Refresh View" button within the "Step 2" section of this page.
The files you selected will now appear in the "Step 3" section of the resulting page. Set the "Processor" field as appropriate. Set the "File Type" field as appropriate. Ensure that the release date for each file matches the release date you submitted for the file release. Once all settings are correct for a file, make use of the "Update/Refresh" button for that file. Repeat this process for each file you have added to the file release.
Once you have completed the process of setting the properties for each file in your file release, please proceed to "Step 4". In the event that users are monitoring this file package, please consider sending them notification of this file release. To send notification of a file release to those users monitoring the package, ensure that the "I'm sure" check box is checked, then make use of the "Send Notice" button.
Updates to project download pages are currently performed on a 30 minute cycle. While changes and additions to your file releases will be reflected immediately in the admin interface for the file release system, it may take up to 30 minutes for your changes to be reflected on the download page for your project.
^ Shadowing the actions of your end-users: testing
your releases » |
doc feedback |
support
The final step in performing any file release should be verifying the integrity and proper function of that release one last time. Download each of the files from your release to a separate location and verify that their contents match the contents of the files you uploaded. This will help to ensure that your file has not been tampered with or damaged during the file release process. You may use utilities such as diff, md5sum and comp to compare files easily.
Extract or install each of the files you have released and verify that the installation goes as you expect. It is clearly better to catch fundamental issues with a file release before the bulk of your end-users run in to the same issue. Should you encounter an issue with your file release, simply re-upload the file in question, remove that file from the existing release, add the new copy of that file from the incoming tree and set its properties as you have done previously. Always retest files you replace to ensure that new issues have not been introduced during the file replacement process.
^ How
much disk space do I get for storing my file
releases? » |
doc feedback |
support
SourceForge.net does not currently place any limitations on the amount of disk space each project may use on the project download servers (which are fed by the SourceForge.net file release system). We do ask that you keep your disk usage and release schedule realistic; this will help us to ensure that we may continue to use this open-ended quota policy. It should be noted that there ARE restrictions on disk usage on the project shell servers (both user home directories and project group directories).
^ How can I see how many people have downloaded one
of my released files? » |
doc feedback |
support
SourceForge.net collects statistics on how many downloads have occurred for files released through the file release system. These statistics are aggregated daily (updates to the statistics listings do not occur in real-time). To view the download statistics for your file releases, simply go to the download page for your project. Download counts will be listed in the "D/L" column on that page.
^ What should I include as file
releases? » |
doc feedback |
support
The obvious answer: sources. As stated, SourceForge.net does not make any demands as to how often project administrators perform releases. When a project does decide to make a file release, the obvious course of action is to generate a .zip archive or .tar.gz (compressed tarball) of their sources.
Be sure to include a copy of your license information within your source archive. Most projects include at least a basic README describing the purpose of the software and include links within that document for places their end-users may get support for the software. Build your source archive; check its contents, the permissions on files and directories, and the directory layout within the archive. It is always easier to check the archive before a lengthy upload.
Many projects have test teams which will verify the basic functionality of release archives before those releases occur. If your project has grown to have a significant user base, this is definitely something you should consider.
If you are providing binary archives through the file release system, please ensure that the sources for those binaries are also available, as required by the license governing that software. Generally, it is also a good idea to include some form of change log (descriptions of functional differences between releases) and release notes within your release archives. The more suitable the documentation you provide within your release, the less likely your end-users will require your support.
^ What types of materials should I NOT
include in my project file releases? » |
doc feedback |
support
Each project is responsible for their own content. It is important that you observe the Terms of Service for SourceForge.net. You should not include material you are not licensed to distribute, closed source materials, or other content which is unacceptable for posting per the Terms of Service agreement. In the event that you encounter a project which has released materials of this nature, please first notify the administrator of that project; failing resolution through that course of action, please notify the SourceForge.net team by submitting a support request.
File release data is persistent; SourceForge.net generally stores this data indefinitely once it has been added to the file release system. Files which are of only temporary benefit, or which have a far more limited audience than your project end-users, might be better served from your project web space than from the file release system.
^ How can I include in my project's file releases
those materials which we released before moving to
SourceForge.net? »
|
doc feedback |
support
The SourceForge.net file release system is fairly open-ended. If your project wishes to post materials which were released previous to your project moving to SourceForge.net, first verify that those materials were released under an Open Source software license. Only Open Source software may be released on SourceForge.net.
Pending successful verification of license terms, simply perform a standard file release. Upload the file(s) you wish to include on these releases. The only change you need make during the standard release process is to back-date the release (set the "Release Date" field on the release and each file within that release to match the date of the original file release).
^ How
does the file release system relate to project CVS
services? » |
doc feedback |
support
The SourceForge.net file release system is not directly related to project CVS services. Both are entirely separate subsystems within the greater SourceForge.net system. Content may be exported from your project CVS repository, be packaged, then released under the file release system; it is important to understand, however, that CVS generally has little to do with the file release system. CVS exists to provide you with a means to enhance your development practices (by storing file history for each file you develop), whereas the file release system exists to help you distribute your files (in ready-to-use form) to the general public.
^ How can I change the details of an existing file
release? » |
doc feedback |
support
To change the details of an existing file release, access the file release interface. Make use of the "Edit Releases" link next to the package whose release you wish to change. Make use of the "Edit This Release" link next to the release you wish to edit. Modify the release as necessary, within the Step 1 through Step 3 sections of that page, making use of the "Refresh" button for the related section after changes to that section are complete. Once your changes are complete, consider sending an updated release notice to those users who are monitoring the package (see the "Step 4" section of the page for details) if you have made significant changes to the release.
^ How can I remove an unwanted file release from
the file release system? » |
doc feedback |
support
Once a file release or package has been created, there is no means to completely delete it from the file release system. You may, however, flag unwanted releases as "hidden" (rather than their current "active" status) by using the "Edit/Release Files" link on the Project Admin pages for your project. Keep in mind that you may re-use file releases in the future, so while you cannot delete the unwanted releases, they may be renamed and re-activated for your next release.
^ How can I remove an unwanted package from the
file release system? » |
doc feedback |
support
Packages may be flagged as hidden by first flagging all contained releases as hidden, then by changing the package status flag to hidden. These changes may be accomplished by editing a package and its releases.
^ Should I remove older file releases to save
you space? »
|
doc feedback |
support
In short, no. One of the major benefits of Open Source development comes in retaining historical file releases for your project. Old releases can be an important debugging tool. Old releases can help show the development efforts of your team. Other people may have reasons to run older releases, depending on file format changes or resource requirements. Code included in old releases, while having been discarded for newer releases, may prove useful for other projects. SourceForge.net has the space to store a large amount of release data in the long-term. Keep your old releases around: for your benefit and for the benefit of your end-users.
^ How can I let another member of my team perform
file releases? » |
doc feedback |
support
As the project administrator for a project, you may edit the user permissions of the developers on your project team. Before a team member may release files through the file release system, they must have the "Release Technician" flag enabled on their user account.
- Go to the Project Admin page for your project.
- Select the "User Permissions" link on the Project Admin page for your project.
- Select the desired developer name from the team member listing.
- Ensure that the "Release Technician" box is checked.
- Make use of the "Update Developer Permissions" button at the bottom of the permissions form.
^ I am a project administrator and it seems
like I don't have sufficient permissions to perform a file
release; how can I fix this? » |
doc feedback |
support
As the project administrator for a project, you may edit the user permissions of the developers on your project team. Before you may release files through the file release system, you must have the "Release Technician" flag enabled on your user account. Follow the instructions for updating developer user preferences.
^ Organizing and Managing your SourceForge.net
Resources as Related to your File Releases » |
doc feedback |
support
As a project administrator, you are likely looking to make your project operations as streamlined as possible, cut down on the amount of time your team spends dealing with issues, and keep things as simple as possible (the KISS principle). Based on our experience in hosting projects on SourceForge.net, we offer a few tips, as related to your file releases:
- If your project uses a CVS repository, it is generally a good idea to match the module names for different major components to the file release package names for those same components (if those components are split in to separate packages at time of release). This makes locating specific materials in your CVS repository considerably easier for potential developers, and helps to keep things straight with existing developers.
- Keep in mind that a single project shares the same CVS repository, bug tracker, support request tracker, forums, and mailing lists no matter how many packages are released by that project. If a single project releases a large number of very different packages, managing the other aspects of the project can become more difficult. It is often better to register separate projects for each major subject a team chooses to undertake, rather than adding clutter to a single project.
- If you want users to ask for support in a certain manner, document that fact. Include this type of documentation in your file releases, on your project web site, and in the release notes for your file releases. The more concentrated your support effort, the less overhead is involved in providing support.
- If your project releases several different packages, consider adding a Tracker category for each package. This permits you to separate issues easily by package and ensure those issues reach the appropriate developer or support staff in a timely manner.
- Similar may be said of forums and mailing lists. It is our recommendation, however, that you start with a generic forum or mailing list for users, and similar for developers; if volume warrants, then consider splitting out a separate forum or mailing list for each package.
- Release materials from your project in a consistent manner. Include the same basic directory structure with each of your releases. Most Open Source software development projects include all contents under a directory with the same name as the file (i.e. if we are releasing boxmodel-1.0.tar.gz, all contents within that archive would be under a directory structure named boxmodel-1.0). Include consistent documentation within each release. Consistency helps avoid confusion (if you use a reasonable release structure to begin with).
^ May I
upload my file releases using SSH, SCP or
SFTP? » |
doc feedback |
support
The SourceForge.net system does not currently provide the means to perform file releases using SCP or SFTP. Only anonymous FTP is supported at this time. It is our expectation that file releases do not contain proprietary or secret information (they are, after all, going on to a publically-accessible download server). If you are concerned about security, perform your file release, then re-download your files from the server to verify their integrity.
You may also choose to include GNU Privacy Guard or PGP signatures for your file releases (simply include them as files within your file release). If you do have concerns about end-to-end file security, you may first upload your files to the group directory for your project on the project shell servers, then perform the file release from there.
^ Why
doesn't my SourceForge.net username and password work on the
upload.sourceforge.net server? » |
doc feedback |
support
FTP is, by design, an insecure protocol. For this reason, your SourceForge.net login is not accepted by the file release upload servers; only anonymous logins are permitted. The reasons for this are documented in the site documentation titled, "Why can't I use TELNET and FTP to reach SourceForge hosts?"
^ Download server details » |
doc feedback |
support
SourceForge.net makes use of a network of high-capacity download servers. These download servers are geographically distributed (not all located on the same network, or in the same city). All SourceForge.net download servers are streamlined for the task and have no other duties (they are dedicated machines). The traffic capacity of the SourceForge.net download server network currently exceeds 1000 concurrent FTP connections and 3000 concurrent HTTP connections.
When a file release is performed, a master download server is updated in real-time. Updates are pushed from that download server out the other servers in the download server network on a one-hour interval.
^ Where can I
obtain support for the file release system? » |
doc feedback |
support
The SourceForge.net support team is happy to assist with any issues related to the services we offer, including the file release system. To contact the SourceForge.net support team, first login to the SourceForge.net web site, then submit a support request.
Return to the top of this page.
© Copyright 2002-2004 Open Source Development Network. All rights reserved.
Powered by the SourceForge® collaborative development environment from VA Software
©Copyright 2006 - OSTG Open Source Technology Group, All Rights Reserved