On Tue, 15 Feb 2000, Andrew Brown wrote:
# >#### TANGENT!!! ####
# >On the naming convention for releases, should we perhaps start calling
# >them Major.Minor.Patchlevel.NumericRelease? Or would it be too confusing
# >to reference 1.4S as 1.4.0.19 (vs 1.4.1)?
#
# it should probably be actually be 1.4.19.0, but i'm not sure it'll be
# a popular idea. :)
I figure 1.4.0.19 because 1.4S does NOT branch off 1.4.1, but rather
off 1.4 as a development branch. The reason I thought it would be mis-
leading is because 1.4.0.19 would appear to be a lesser rev than
1.4.1, even though 1.4.*0*, specifically (vs 1.4) could be taken as a
current version.
The alternative is to release as major.minor.numeric.patchlevel, so
what is now 1.4.1 would be called 1.4.0.1, and 1.4.1 would be the branch
from current, but that's not entirely sensible either.
# >It would certainly solve the 1.4<letter> convention and save us from
# >running out of chars...
#
# but instead we'd be using up more. letters are a much more compact
# form of representation.
Yes, but going beyond Z means either going to 'a' as you suggest below,
or going to AA or some other multi-char scheme. The former is confusing
because if you're talking about Maj.minA vs Maj.mina, how do you know
it's not a typo or something? The latter screws up any hope of keeping
__NetBSD_Version__ straight, especially if that version number is
generated as opposed to manually entered. It just opens a whole bag
of spaghetti that way, is all.
Hopefully, though, this will all be moot and we'll hit 1.5 before
we have to go to 1.4Z++.
#
# btw - what would be wrong with simply going from 1.4Z -> 1.4a? it
# satisfies the ascii sort order, and would fit into the "kernel version
# letter - '@'" methodology.
See above, but it's probably more sane than anything else I've seen
(or suggested).
I could see, though that people might wonder what happened to versions
104270000 thru 104640000 :-).
[I'm sorry -- I guess it is kind of silly.]
--*greywolf;
--
NetBSD: safe ports in a storm.