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,...-jmppPS: 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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
