bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Stable releases / Release engineering / CVS / Daily Snap


From: Russ Allbery
Subject: Re: [Bug-gnubg] Stable releases / Release engineering / CVS / Daily Snapshots etc...
Date: Tue, 19 Mar 2013 21:45:35 -0700
User-agent: 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:

> 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 (address@hidden)             <http://www.eyrie.org/~eagle/>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]