From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-28 01:37:48
Christopher Currie wrote:
> > Up till now, I only bumped version number when doing V2 releases. The
> > motivation was that for releases, the check is really necessary,
> > while for persons who use CVS version, rebuilding jam after each CVS
> > update is not a problem. If we bump version after adding each
> > builtin, the version number will grow very quickly. Of course, other
> > opinions are welcome.
> While in theory I agree, it's no big deal most of the time, for folks
> like me who like to help out but have limited time and can only keep
> up-to-date as time permits, having that version updated saves me time of
> debugging why my tests don't build anymore.
I see. While error message about CALC is clear for me, it's not clear when you
update Boost.Build and start getting the error?
> > Hmm, not sure what is better, to bump right after each release, or
> > right before each release. I haven't done the version changes so I'll
> > hold off on doing that now :-)
> My personal preference is to bump right after each release. This
> prevents someone from checking out CVS, building jam_src, and having it
> report itself the same as a released version.
> I think we should minic the gcc model, where the version is bumped and
> set to X.Y.Z-alpha or something similar, right after release, and then
> the alpha is dropped right before release. Or if you don't want to deal
> with letters in the version number, we can imitate the linux model,
> where odd numbers are development and even numbers are release, or
> something similar.
> But I understand that it's a maintenance headache to do that, so if you
> don't think it's worth the trouble, I completely understand.
Well, given the length of current 'release_procedure.txt', an extra step of
bumping version after release is nothing :-). But will that solve the
problem? I mean, we can introduce 3 new builtins between milestone releases.
If we don't bump version each time, it can cause the same problem for persons
who update their Boost.Build tree.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk