Project releases must be coordinated with all parties actively involved in the project. There are several other things involved before making a release.
There are some files that must be there while others are optional. The mandatory files are:
README -- miscellaneous notes.
INSTALL -- installation instructions.
AUTHORS -- list of author. It should simply be the author name followed by the email address, line by line.
COPYING -- this file should contain the license that is being used for the project, be it GPL, BSD or any other Open Source license.
ChangeLog -- this file has been discussed earlier in theChangeLog
There are always people who have helped with the project in one way or the other but are not listed in the AUTHORS file. This is where you can mention them in a file named THANKS. Always give credit where it is due. That is an absolute must.
This may seem obvious, but mistakes do happen. It is not uncommon to have several directories with different versions of the software you are working on. Once you have decided what files you will include in your release, make a copy of them in a new directory and try compiling it then running it. Ensure that you have all the right and necessary files there.
It may be best to use the cvs command cvs export in order to create a copy of the source tree without the CVS administrative files. You may also want to automate this process as much as possible. However, it is entirely up to you how you handle this.
All tarballs should be named as follows: pkgname-verion.tar.gz (or .tar.bz2/.tgz/etc.). They should also untar into a directory by the name of pkgname-version/. It should never untar into the current working directory or simple pkgname/.
In order to make it easy for a user to know what to expect from a particular project's version, we will use certain conventions in our version numberings.
The version scheme should be <major-revision>.<minor-revision>.< bugfix-revision>. The major revision reflects major changes in the program. The minor revision reflects the general status of the code (beta or stable). The bug-fix revision is optional. They constitute changes that only involve bug fixes or very minor changes. The only exception to the above rule are alpha releases.
Alpha releases are what one can call, 'bleeding-edge' releases. Alpha releases often contain new code with features not thoroughly tested yet. Alpha releases should only have <major>.<minor> version numbers attached to them. In the case of a new project which does not have any release yet, you will use 0.0 as the version number. For example, pkgname-0.0.20030428.
Beta releases are one step better than alpha releases. Generally beta releases should be released after some feedback was received post an earlier alpha release. Beta releases are denoted by odd version numbers. For example, pkgname-1.3.
Stable releases should only be made when feedback and tests have been performed not only by the developers and active testers, but by end-users who are not interested in the development of the project (but only the use of it). This is particularly important to observe, in order to maintain a high standard of expectations for all releases.
Stable releases should simply include the package name followed by an even version number. For example, pkgname-1.4.
Before a major release, sometimes it is preferable to do 'last-minute' testing. Generally this should only be used for large projects. However, a maintainer may elect to release several quick and small releases without wanting to increment the version number. This is particularly true when the changes are quick and small bug-fixes.
Release candidates should have the package name followed by 'RCx' where x is a number to be incremented as necessary (starting from 1). For example, pkgname-1.5RC2, is version 1.5 release candidate 2.
It should be noted however, that this option should only be used for very large projects (like Arabbix for example). Smaller projects should not have to deal with release candidates.
Whenever you are about to make a release, you must tag the CVS. This makes it possible for you to go back to a specific version from CVS without having to remember every file's revision number.
Tag names should be as follows PKGNAME_x_x. Also note that the tag should be in all capital letters. If it is an alpha release then simply name it PKGNAME_xxxxxxxx.
To tag your project, simply issue the 'cvs tag' command. For example:
$ cvs tag -R QAMOOSE_2_0
|
Once you have prepared your tarball and any other distro-specific package (be it DEB or RPM or any other package), it is time to release your program to the world. You need to let the world know!
Upload the files on ftp://upload.sourceforge.net. If you are a project maintainer and do not have a sf.net account, create one. If you do have one but are not listed as one of the developers on the Arabeyes project then request to be added by emailing 'contact (at) arabeyes dot org'.
You should simply follow the instructions provided by SourceForge on how to add a new release.
Announce on Arabeyes.org
Post an announcement on the Arabeyes announce list. Be sure to include important information such as: version number, what's new and the changelog.
Post a short announcement on the project page (if you are the project maintainer you should have access to do that). Keep it short and to the point. Link to the archived announce message you posted earlier on the 'announce' list.
Post an annoucement on the Arabeyes general list. Unfortunately not everyone is on the 'announce' list and there are more people on the 'general' list. For this reason it is a good idea to re-post the announcement on the 'general' list. Please do NOT cross-post (post to announce and Cc general). This is deeply frowned upon and will cause the list manager to yell and scream at you ;)
Announce on Freshmeat.net. Arabeyes projects are listed under the user 'arabeyes'. If your project is new, please do ask one of the Arabeyes managers to add your project and do the first announcement for you.
If your project is already listed then simply add a new release. The projects are set that anyone with a freshmeat.net account can update. We use the honor system here, until something goes wrong ;)
Announce it anywhere else you like (e.g. linux4arab.com, arabiclinux.org, arabiclinux.com, linux-egypt.org, etc.). This depends on how important you think your release is (or how much time you have to spend on it!) The general rule is, the more people learn about it, the more likely you will get attention.
Now the world knows about your project and your new release. Wait for the feedback! Very often, people will not offer feedback when you are asking for it before the release. Once you make your release you will notice that people will start giving you feedback. That is why, it is always good to release early and release often.