This chapter describes the system for releasing Netpbm: when releases are made, what's in them, and how a user gets a release.
Releases are primarily made via Subversion. A user may download the code by checking out the Subversion branch from the Sourceforge Subversion repository.
Some releases are also distributed as gzipped tarballs via Sourceforge file release services.
Before 2013, one could get a tarball of any release, via the Sourceforge Viewvc service, but Sourceforge withdrew that service.
There are four series of releases. There is a subversion branch for each series. The current code in the branch is the current release for that series.
Except in the Development series, all releases have a name like 11.01.03. You find those numbers in the file version.mk (Makefile.version in very old releases) in the top directory of the source tree. In the Development series, releases aren't numbered. A release number uniquely identifies a release across all series. Sometimes, you find the same release number in multiple series, but in that case, the code is guaranteed to be identical.
Each series is a directory in the Subversion repository.
The series are:
The directory name in the Subversion repository is trunk.
This is a conventional Subversion trunk.
Releases are unnamed; we make new releases frequently, possibly minutes apart (every Subversion commit constitutes a release). These can only barely be considered releases (but they are, because the code is available for use by the public -- it has been "released.").
The current release in this series has the newest function of any release.
The code here is barely tested. It has lots of bugs. It may not even build. A user of this code should be prepared to do debugging.
Probably the main reason to use these releases is that you're doing development work and want to merge it with the latest development work done by others.
The directory name in the Subversion repository is advanced.
This series stabilizes for about a quarter year, then is rebased to the then-current Development release.
"Stabilizes" means that new releases contain only low risk high reward changes from the previous release. That's typically bug fixes, but some enhancements fit the category and some bug fixes do not.
We make a new release within a few days of developing a fix for any bug. So the current release normally has no known bugs, but because of the frequent rebasing, it typically has quite a few undiscovered bugs.
The minor release number changes with each rebasing. The point release number changes in between. So for example, assume the current release is 11.02.03. Suppose a new release comes out to fix a bug in 11.02.03. The new release is 11.02.04. Now suppose the series gets rebased so that the next release is identical to the current Development release. That release is 11.03.00.
This series has all development more than 3 months old, and few enough bugs to be generally useful.
The directory name in the Subversion repository is stable.
This is like Advanced, except that it gets rebased to the then-current Advanced release instead of Development, which means it the current release always has at least 3 months of stabilization.
When it is time to rebase the Advanced series, if the current Stable release has gone a whole quarter year with no reported bug, we move all the current releases down one series: Stable becomes Super Stable, then Advanced becomes Stable, then Development becomes Advanced.
The release numbering in this series is just a continuation of the numbering in the Advanced series. So for example, assume the current release is 10.41.09. Suppose a new release comes out to fix a bug in 10.41.09. The new release is 10.41.10. Now suppose the series gets rebased so that the next release is identical to Advanced release 11.02.03. The new Stable release is also called 11.02.03.
Because the base of this series is old, it sometimes doesn't work in newer systems. For example, a recent compiler might not be backward compatible with the ones that were in use when Netpbm Stable was developed, and may fail to compile Netpbm Stable. Netpbm Stable is most appropriate in a stable complete system.
The current release in this series has no known bugs and virtually no undiscovered bugs in it. It may be years behind in new function.
The directory name in the Subversion repository is super_stable.
This is a continuation of the Stable series from before the most recent rebasing of it. For example, assume the current Super Stable release is 10.26.40 and the current Stable release is 10.41.10. Suppose the Stable series gets rebased so the current Stable release is 11.02.03. At that time, the 10.41.10 release moves to become the current Super Stable release; the next Super Stable release is 10.41.11, and so on.
All releases in this series are available as a tarball from the Sourceforge File Release system, as well as from Subversion.
Because the base of this series is old, it sometimes doesn't work in newer systems. For example, a recent compiler might not be backward compatible with the ones that were in use when Netpbm Super Stable was developed, and may fail to compile Netpbm Super Stable. Netpbm Super Stable is most appropriate in a stable complete system.
Sometimes you want to see the code for a certain release number, e.g. 12.02.02. It's fairly unusual -- normally, you want the latest code in a series -- but there are reasons. One common reason is to find out just when a certain thing changed.
There are two ways to do that.
For a .00 release (e.g. 11.02.00), look in the directory release_number in the Subversion repository. There is a subdirectory under that for each .00 release.
For other releases, it's a little harder (but, thankfully, a lot less common). You have to find out the Subversion commit level that applies to that release. To do that, you look at the Subversion change history for the Netpbm source file version.mk or Makefile.version. That file changes at least once for each version, usually accompanied by a commit comment saying it's a new release.
So do a svn log of version.mk or Makefile.version in one of the series. If you're looking for 10.42.03, you could use
STABLE_ROOT=http://svn.code.sf.net/p/netpbm/code/stable
svn log $STABLE_ROOT/Makefile.version
In the output, you will see the Subversion commit level that corresponds to
each version:
------------------------------------------------------------------------ r47 | giraffedata | 2007-09-11 00:01:51 +0000 (Tue, 11 Sep 2007) | 1 line Release 10.42.03 ------------------------------------------------------------------------
With the commit level in hand, you can check out the code for that release. Assuming the commit level is 47 as shown above, the command would be
STABLE_ROOT=http://svn.code.sf.net/p/netpbm/code/stable
svn checkout $STABLE_ROOT --revision 47 netpbm-10.42.3
The only really hard part is that you have to guess which series to look in. In the example, we knew it would be Stable, but in other cases, you might have to look in Advanced, Stable, and Superstable until you find it.
This chapter describes the release system that was in use before the current one and the reasons for abandonning it.
There are 3 things the change is meant to make better:
There were two release series, Stable and Latest. Latest releases were 2-3 months apart. Every year or two, we copied the current Latest release as the new Stable release. Between those copies, we made new Stable releases that made stabilizing (low risk, high reward) changes to the previous Stable release.
Therefore, users had a choice between a release containing code at most 3 months old in terms of development (Latest) and a release containing code as old as 18 months (Stable). Latest former typically had a lot of bugs, some fairly critical, while the Stable had no known bugs and typically few unknown ones. However, at the beginning of a Stable series, Stable had plenty of unknown bugs. At that time, there was a third reasonable option for users: the latest of the prior Stable series. That release had a few known bugs, but overall it had practically none. But it could be years old.
All releases were via source code tarball, via the Sourceforge file release system. Each release was also available as a patch file to create that release from the former one. The patch file was available via the Sourceforge file release system as well.
There was no way for anyone but the Netpbm maintainer to see development since the last Latest release except to work with the Maintainer personally.
This system was in use from November 2002 to August 2006. The first release of the first stable series was 10.11.1.
Before that, there was only one release series. Each release contained all of the development and fixes that existed as of the release date. Releases were typically a month apart, but sometimes closer when there was a bad bug.