On Thu, 3 Feb 2000, Alistair G. Crooks wrote:
>
> >   Sounds good, but why not have any non-numeric followed immediately by
> > a number evaluate to .0.<n>?  This way we wouldn't have to immediately
> > change a whole bunch of packages.  Also, versions like 1.1a1, 1.1b1, and
> > 1.1p1 usually indicate completely different things (such as 'alpha',
> > 'beta', or 'patchlevel') which may not even be netbsd-specific but
> > rather have been introduced by the original author.  Changing all these
> > to 'nb' would cause us to lose some information.
> > 
> >   As for NetBSD-specific changes: yes, I believe changing things like
> > '1.1abs1', '1.1rh1' to something common like 'nb' would be a good thing
> > ...
> 
> Because different packages (from trafshow to exmh to lsof) use
> non-numeric suffices in different way. When a package uses the "p1"
> suffix, does it mean patch 1, or pre-release 1? Similarly, does
> 1.1a mean 1.1 alpha, or 1.1 patch 1?
> 
> These are the reasons that non-numeric support has not been added
> to the dewey decimal matching routines.
> 
> I think that abs's suggestion is great, and wish I had thought of
> it myself.

	We could treat the switch from a numeric character to non numeric
	as '.0', and the treat each non numeric char as '.<ascii_value>',
	with nb as a special case of 0.0.

	so, in increasing age we would have:

	1.2	-> 1.2
	1.2nb7	-> 1.2.0.0.7
	1.2a	-> 1.2.0.97
	1.2a1	-> 1.2.0.97.1
	1.2ab	-> 1.2.0.97.98
	1.2ab9	-> 1.2.0.97.98.9
	1.2ab10	-> 1.2.0.97.98.10
	1.2p7	-> 1.2.0.112.7
	1.2pl4	-> 1.2.0.112.108.4
	1.2pl7	-> 1.2.0.112.108.7
	1.2.4	-> 1.2.4

	but this is probably more mess than we want (and I don't even want
	to think about bizarre versions such as '1.2.a')

	Thinking about it more - in my original suggestion we cannot tell
	the difference between 1.2.0.1 and 1.2nb1, and in the above we can
	also get conflicts with large numbered numeric versions and
	versions with non numerics...

	To do this right we really just need to consider the number as two
	components, so the two examples above would be
		1.2.0.1		1 2 0 1 and 0

		1.2nb1		1 2 	and 1

	iff the first components match, compare the second.

	This should be trivial to implement, and I think we should do it.

	We _could_ extend this to arbitrary text in a.. uh... interesting
	fashion by going to two dimensions, plus the extra component -
	taking a horrific example:
		1.2bob.3pl7nb9

		1   2   3  	and 9
		0   bob pl 
		0   0   7  

	This will allow the above to compare sanely to say 1.2bob.3pl10