In message <20030424141111.GN18587@mewburn.net>, Luke Mewburn writes:
>On Wed, Apr 23, 2003 at 09:55:00PM -0400, Andrew Brown wrote:
>  | >> And while I'm here, I could just as well say my opinion on this: I thin
>k
>  | >> bumbing -current's version to "just_released + 1" is a good idea. So,
>  | >> we'd be now at 1.7R. And I don't think it's a problem if it is not know
>n
>  | >> beforehand what the actual release will be called. If there won't be
>  | >> 1.7, fine. 1.7ZZZA just becomes 2.0 then (and -current 2.1A).
>  | >
>  | >Yeah, it probably would be the cleanest.
>  | 
>  | so we're currently at 1.6R, which will lead to 2.0 (followed by 2.0.1,
>  | 2.0.2, etc, as needed), at which point current becomes 2.1A (followed
>  | by 2.1B and 2.1C, etc), and when we're ready, 2.2 gets branched, at
>  | which point current becomes 2.3A, etc.
>
>here's my take:
>
>when we branch 2.0, it's identification becomes "2.0_BETA1".
>as the branch stabilizes, it goes to
>	2.0_BETA2 ...  2.0_BETAn
>	2.0_RC1 ... 2.0_RCn
>	2.0
>(this is what would happen anyway, and is what occurred in 1.6)
>
>after the time of the 2.0 branch, current becomes "3.0_ALPHA1".
>when we need a bump for kernel bump in current, crank to 3.0_ALPHA2, (etc)
>
>once 2.0 is released, the netbsd-2-0 branch is ID-ed as "2.0_STABLE".
>when its ready for the next "minor patch" release, it would change
>to "2.1_BETA1", (etc)
>
>when 3.0 is branched as netbsd-3-0, it changes to "3.0_BETA1" and
>-current becomes "4.0_ALPHA1", and so it goes ...
>

Or use a prefix -- what's now 1.6R will be pre-2.0R, succeeded by 
pre-2.0S, etc.  Quasi-stable ones drop the prefix, but add RCn or BETAn 
as a suffix.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)