Dag-Erling Smorgrav wrote:
> Peter Wemm <[EMAIL PROTECTED]> writes:
> > http://people.freebsd.org/~peter/stdio.diff3
> Except that we bump to 500 instead of 6, and back to 5 before
> When we've branched RELENG_5, if we need to bump libc's major in
> 6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we
> want, and bump it down to 6 before 6.0-RELEASE.
> People tracking -CURRENT will end up with a handful of different libc
> versions, but they'll avoid the pains we're going through now, and
> people upgrading from RELENG_N to RELENG_N+1 will never see a libc
> major version increase of more than 1.

I think this is the least evil of all.  I totally support this option.
It gives us a nice stable sequential *-RELEASE version numbering sequence
without holes.

It avoids the current problem:
- RELENG_4 bumped from 3.0 to 4.0
- this forced a premature 4.0->5.0 bump in -current
- we missed our chance for major changes. (!!!)

If we had taken -current to 500, we could go to 501, 502, etc as 
required to stop killing our developers, and prior to entering 5.0-BETA we
go back to the next sequentially available major number (be it 5, or 6
if RELENG_4 bumps again).

"All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to