[Bug-gnubg] gnubg release schedule

[Gary Wong]

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?

Cheers,
Gary.
-- 
   Gary Wong           address@hidden           http://www.cs.arizona.edu/~gary/