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 GNU Backgammon Developer OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 _______________________________________________ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg