On 14 Aug, 2007, at 16:01, Juan Manuel Palacios wrote:
And as a side (but relevant) note, notice that our version number is really just a floating point number (as defined by base/config/ mp_version) that we simply interpret in the more common x.y.z way, so that gives some more leeway there. I would, however, love to switch our practice to the common software versioning scheme, but that implies using the internal rpm-vercomp function in the selfupdate proc in macports1.0 (which currently only does a simple $old_version < $new_version? mathematical comparison). That's a future project of mine, but if anyone is interested in beating me to it, then by all means! ;-)
As a side-note to your side-note, it might be better to use the `package vcompare` command. This is a Tcl built-in so we wouldn't have to worry about pextlib. Unlike rpm-vercomp, it only handles numeric components, but fortunately, we only release MacPorts with sane version numbers.
So, in a nutshell, I could go either way with 1.5.2 or 1.5.11, whatever people prefer. I would just love to know the final status of the mtree validation feature to asses if I should release *now* or wait for some further debugging/developments. Markus...?
I guess setting the deadline for tomorrow morning (GMT -4) is not too drastic... Regards,...
-jmpp
PS: I just noticed that the sole introduction of rpm-vercomp in selfupdate, to be able to use the x.y.z version format, would itself place some stricter rules on our versioning practices. We humans would recognize that 1.5.11 is a very small release only meant to correct very specific errors in 1.5.1, and therefore we would easily if not immediately realize (I believe) that 1.5.2 is a progression over the former... but not so in rpm-vercomp's words: 11 < 2 is *not* true in anyone's book, neither in rpm-vercomp's ;-) Anyone wanting to work on this should take a time to propose some versioning guidelines and discuss them openly for general adoption.
I'm not sure I agree with your statement about 1.5.11; that's not a proper way of indicating a minor change to 1.5.1, but an incremental change after 1.5.8, 1.5.9, 1.5.10. The proper representation would be "1.5.1.1". Both rpm-vercomp and package vcompare understand 1.5.1 < 1.5.1.1 < 1.5.2. What is problematic is that 1.511 > 1.6.0, so there would have to be special handling in order to upgrade to a version that did proper version comparison. Probably the easiest thing would be to change the path to the version number and leave the old one for legacy support. Chris