[Bug-gnubg] Stable releases / Release engineering / CVS / Daily Snapshots etc...

[Michael Petch]

Howdy All,

This is a collection of my thoughts on recent topics that have been
brought up the past couple weeks in the areas of release engineering,
stable releases, etc.

No project is the same, and GNUBG is rather interesting in that it has
been around over a decade and hasn't achieved a version 1.0 status or
been officially taken out of alpha testing. To me this isn't really
about the product not being stable, but no one sitting down and creating
a road map of what makes our product release quality, whether it
currently is release quality, or what would be required to make it
release quality. If we did so we could put our foot down and define what
we mean to be stable and what 1.0 means to us.

I'm going to offer an opinion. This project is a long term maintenance
project in many respects. Our usage of CVS (revision control) suggests
that as well. I personally believe that the project is generally stable
on the trunk (head) and most developers over the years have tried to
keep it that way. On occasion for major changes some branches were
created to do work that was then merged back into the trunk. This isn't
uncommon. Where we may have taken some shortcuts is on our lack of
proper tagging for specific build numbers in CVS.

In most other projects that use CVS I've been accustomed to Tag/Pull
Tag/Build. For all future builds (starting now), I'm going to do just
that. CVS will be tagged for each build number as:

release-major#_minor#_build#

This would correspond to display values akin to:

major#.minor#.build# (ie. 0.91.1).

Each new build gets its own build number independent of the date it was
compiled. I'll set up the autogen/autoconf magic to allow this to be
adjusted more easily.

What I have done in the past is to find points in the trunk that build
across multiple platforms without error, and then I sit down and
actually do some testing prior to releasing. When I believe the code is
stable I then produce a build. It is rare that we ship out a new windows
build with serious regression issues. Before anyone asks, no there is no
automated testing that is done (that can be looked at if someone has
time). I usually do some sanity checks, and make sure that items in the
Changelog work as expected (I will often review the code and make
adjustments if I see something was missed). Prior to an official release
you'll often find a series of updates from me for such changes.

Once a build is tagged in CVS, most projects do main development along
the trunk. If there are builds that are considered long term stable,
then a branch is created for those builds. Usually something like:

release-major#_minor#_build#_patches

Bug fixes are usually applied to the patches branch and to the main
trunk. Our project works a bit differently since we have a reasonably
stable trunk, and our trunk has become pretty much THE long term stable
release with incremental patches. If we decide on a release 1.0.0 we
might start considering that we have a long term stable (LTS) release
with which minor fixes are applied along with main development on the
trunk. I leave that open for discussion.

With proper CVS tagging anyone who needs code for a particular build can
simply pull by tag. Given that some testing has occurred prior to these
releases, one could probably consider them stable enough to be
considered for use in other distros. something that I will be doing is
to supply a source tar ball along with each build in the future. This
way downstream maintainers like Russ Allbery would have easy access to
stable source tarballs for their own use.

Normally when I build for Windows I also make sure it compiles with all
options on (SSE2 enabled) for both the GUI and the CLI versions on my
Debian stable boxes sing standard ./autogen; ./configure; make .

This brings us to the other point brought up - snapshots. Personally I
believe they are probably a waste of space in the grand scheme of
things. If we provide source tar balls for each official build this
should be plenty good enough for most. Using CVS to pull the head out is
trivial, and I suspect that most people with simple instructions can
pull a tagged build too. CVS is pretty much on every platform including
Windows. Snapshots might be valuable to those who want to view the code
and have no intention of actually compiling it.

If we wish to keep daily snapshots then I might suggest only generating
them IF there has been modifications since the previous snapshot. This
would eliminate all the unnecessary ones that had no changes. Daily
snapshots would not be tagged in CVS, and should not be used for
official releases or by downstream maintainers.

Questions/Comments/observations/requests are welcome.

-- 
Michael Petch
CApp::Sysware Consulting Ltd.
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304