Re: dpkg doing wrong math (0.09 = 0.9) ?-

[Adam Borowski <kilobyte@angband.pl>]

On Fri, Aug 11, 2006 at 09:47:33AM +0100, martin f krafft wrote:
> also sprach Adam Borowski <kilobyte@angband.pl> [2006.08.11.0931 +0100]:
> > And another bug: "2a.0" is _lesser_ than "2.0"!  This works as
> > documented, but is totally against lexicography, expectations and
> > common sense.
> 
> I'll shoot anyone who uses such a version number. :)

Then I need to invest in body armour.  This is how I mark a release when
only a minimal change that doesn't warrant to have its version bumped in the
regular manner happens.
Fortunately, in all the cases so far the letter was placed after the last
numeric part, so even with a Debian revision attached the dpkg misdesign
would be mitigated as dpkg special-cases the last hyphen.

An example of such a scheme:
  1.0.6
  1.0.6a (a few hours later, with a brown-paper bug fixed)
  1.0.7

In another case, I have an auto-versioning where releases are tagged
0.20060811 (epoch-guard.date).  If two checkouts happen on the same date,
the makefile target will tag the second one 0.20060811a (or b, c, etc).

Or, in file names:
a proxy I wrote will wrote incoming connections to files named
$date.$time.$format.bz2; if two connections come in the same second (a rare
case), the latter will be named "2006-08-11.14-07-58a.bz2", proceeding with
b, c, aa, ab, zz, aaa and so on.
No one uses dpkg --compare-version to sort file names, but in this case, it
would break.


So, is there anything wrong in any of the three examples I shown above?  I
would call that a pretty natural scheme.

-- 
1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.