bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] gnubg release schedule


From: Joern Thyssen
Subject: Re: [Bug-gnubg] gnubg release schedule
Date: Mon, 13 Jan 2003 10:40:25 +0000
User-agent: Mutt/1.4i

On Sun, Jan 12, 2003 at 06:02:58PM -0500, Gary Wong wrote
> Hi,
> 
> Does anybody have preferences or opinions for the way we make pre-releases?
> So far I have been making tarballs at irregular intervals when there have
> been significant improvements and the code has temporarily stabilised, but
> recently (IMO) we seem to be making changes more and more frequently, which
> means that the code never really gets to be especially stable.  We could
> make additional pre-releases anyway, but I think that unless there is some
> reason why we expect the pre-releases are less buggy than the daily
> snapshots, then they're pretty much meaningless.
> 
> Do you think it would be worthwhile to start maintaining "stable" CVS
> branches on which we commit only bug-fixes?  Presumably, such branches
> would be more reliable than the trunk.  From time to time (I imagine on the
> order of every couple of months), we could increase the minor version
> number (0.12 to 0.13 to 0.14, etc.), release 0.13.0 (or whatever) and
> create a new branch.  No new features would be added on the branch; only
> bug fixes.  As we apply fixes, we could release 0.13.1, 0.13.2, etc. as
> necessary.
> 
> The advantage of such a scheme would be that there would be good
> reason to believe the release branch code would be more stable than the
> daily snapshots.  (The pre-release versions might also tend to stay in
> synch with the weights file versions a bit better, which has sometimes
> caused confusion before.)
> 
> The disadvantage would be that bug fixes which affect both the pre-release
> branch and the main trunk would have to be applied twice (or at least
> applied to the branch, and then merged onto the trunk, "cvs update -j"
> style), which means making patches will become more tedious.
> 
> Any comments, other ideas, or preferences?

I think you proprosal with a "stable" branch is fine. Although it'll
probably give some extra work for the builders: most users will most
likely want to run on the "stable" branch, but I'm sure that there are
someone out there who wants the new features X and Y, and just can't
wait for 0.14.0 "stable" :-)

How do we handle the transition from 0.13.x "stable" to 0.14.0 "stable"?
Do we have a feature freeze, say, 2 weeks before the scheduled 0.14.0 release?
Or do we just make a 0.14.0 (and *don't* call it stable yet!), and wait
for it to stabilise?

Jørn




reply via email to

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