This document describes the system for releasing Xmlrpc-c: 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 (or exporting) the Subversion branch from the Sourceforge Subversion repository.
Some releases are also distributed as gzipped tarballs via Sourceforge file release services.
There are four series of releases, with different levels of stability. "Stable" does not mean "without bugs." It means "unchanging." In a stable release series, we make only low risk high reward changes, and as a consequence over time it comes to have fewer bugs than a less stable release series. But it also has fewer features.
Stable release series are primarily meant for stable systems, so they maintain strict backward compatibility. But they also don't have forward compatibility, which means it you try to use a stable Xmlrpc-c release in a modern environment, it may not work. In particular, we often see the releases of the Curl library come out that are not backward compatible, so older Xmlrpc-c, including current releases of stable series, won't work with them. I.e. with old Xmlrpc-c, you have to use old Curl. There is a Subversion branch for each series. The current code in the branch is the current release for that series. You can't easily download any release but the current release in each series. However, Subversion tracks the complete history of code changes, so with a little effort, you can get any old code you want.
Except in the Development series, all releases have a name like 1.16.10. You find those numbers in the file version.mk or 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 two 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. If you think you might want to use this because it has bug fixes that haven't been released in the other series yet, think again. In Xmlrpc-c, bug fixes of any significance are released in all the series as soon as the fix is known.
The directory name in the Subversion repository is advanced.
This series stabilizes for about a quarter year, then gets a major update: it is updated 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 major updates, it typically has quite a few undiscovered bugs.
The minor release number changes with each major update. The point release number changes in between. So for example, assume the current release is 1.12.02 Suppose a new release comes out to fix a bug in 1.12.02. The new release is 1.12.03. Now suppose the series gets a major update so that the next release is identical to the current Development release. That release is 1.13.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 updated to the then-current Advanced release instead of Development, which means the current release always has at least 3 months of stabilization.
When it is time to do a major update of the Advanced series, if the current Stable release has gone 3 months 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 1.06.18. Suppose a new release comes out to fix a bug in 1.06.18. The new release is 1.06.19. Now suppose the series gets a major update so that the next release is identical to Advanced release 1.12.08. The new Stable release is also called 1.12.08.
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 major update of it. For example, assume the current Super Stable release is 1.03.02 and the current Stable release is 1.06.19. Suppose the Stable series gets rebased so the current Stable release is 1.12.08. At that time, the 1.06.19 release moves to become the current Super Stable release; the next Super Stable release is 1.06.20, and so on.
All releases in this series are available as a tarball from the Sourceforge File Release system, as well as from Subversion.
Sometimes you want to see the code for a certain release number, e.g. 1.12.03. 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.
For the first or last point release of a certain minor release, look in the release_number directory in the Subversion repository. There is a subdirectory under that for the first and last point release of every minor release. For example, there is 01.16.00 and 01.16.33.
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 Xmlrpc-c source file version.mk. That file changes at least once for each version, usually accompanied by a commit comment saying it's a new release. In older releases, this file is called Makefile.version.
So do a svn log of version.mk in one of the series. If you're looking for 1.16.03, you could use
ROOT=http://xmlrpc-c.svn.sourceforge.net/svnroot/xmlrpc-c/advanced
svn log $ROOT/version.mk
In the output, you will see the Subversion commit level that corresponds to
each version:
------------------------------------------------------------------------ r1557 | giraffedata | 2008-10-16 20:25:11 +0000 (Thu, 16 Oct 2008) | 1 line Release 1.16.03 ------------------------------------------------------------------------
With the commit level in hand, you can check out the code for that release. Assuming the commit level is 1557 as shown above, the command would be
ROOT=http://xmlrpc-c.svn.sourceforge.net/svnroot/xmlrpc-c/advanced
svn checkout $ROOT --revision 1557 xmlrpc-c-1.16.03
The only really hard part is that you have to guess which series to look in. In the example, we knew it would be Advanced, but in other cases, you might have to look in Advanced, Stable, and Superstable until you find it.
version.mk does not exist (neither does Makefile.version) before Release 1.13, so there just isn't a good way to find numbered releases before that.
Before 2013, Sourceforge had a feature that would make a tarball for you from the Subversion repository, but Sourceforge has withdrawn that service.