12.5 Test Releases

When you release a greatly changed new major version of a program, you might want to do so as a pretest. This means that you make a tar file, but send it only to a group of volunteers that you have recruited. (Use a suitable GNU mailing list/newsgroup to recruit them.)

We normally use the server alpha.gnu.org for pretests and prerelease versions. See Automated FTP Uploads, for the procedural details of putting new versions on alpha.gnu.org.

Once a program gets to be widely used and people expect it to work solidly, it is a good idea to do pretest releases before each “real” release.

There are three ways of handling version numbers for pretest versions. One method is to treat them as versions preceding the release you are going to make.

In this method, if you are about to release version 4.6 but you want to do a pretest first, call it 4.5.90. If you need a second pretest, call it 4.5.91, and so on. If you are really unlucky and ten pretests are not enough, after 4.5.99 you could advance to 4.5.990 and so on. (You could also use 4.5.100, but 990 has the advantage of sorting in the right order.)

Another method is to attach a date to the release number that is coming. For a pretest for version 4.6, made on Dec 10, 2002, this would be 4.6.20021210. A second pretest made the same day could be 4.6.20021210.1.

For development snapshots that are not formal pretests, using just the date without the version numbers is ok too.

A third method, if the package uses Git, is to run the script build-aux/git-version-gen from Gnulib to generate test release version numbers. It generates version numbers in the form ‘version.commits-commithash’, where version is the latest version tag, commits is the number of commits since that tag, and commithash is a hash code for the latest commit.

One thing that you should never do is to release a pretest with the same version number as the planned real release. Many people will look only at the version number (in the tar file name, in the directory name that it unpacks into, or wherever they can find it) to determine whether a tar file is the latest version. People might look at the test release in this way and mistake it for the real release. Therefore, always change the number when you release changed code.