Michael Petch <mpe...@gnubg.com> writes: > 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. This sounds great to me. > 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. I think the current development model seems fine, and I'm not seeing any compelling need to have a stable maintenance branch. The trunk is generally perfectly fine, and there doesn't seem to be a lot of large, disruptive work that folks really want to do on trunk. > 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. That would be neat. :) Although I can pull from CVS tags if need be, tarballs are a little nicer. > 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. Yeah, the only reason why I ever use the snapshots is that it's the only release tarball that exists at the moment. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> _______________________________________________ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg