[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Stable releases / Release engineering / CVS / Daily Snap
Re: [Bug-gnubg] Stable releases / Release engineering / CVS / Daily Snapshots etc...
Tue, 19 Mar 2013 21:45:35 -0700
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Michael Petch <address@hidden> 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:
> 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:
> 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 (address@hidden) <http://www.eyrie.org/~eagle/>