On Aug 14, 2007, at 5:12 PM, Chris Pickel wrote:

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.

macports1.0 already loading pextlib1.0, what benefits would vmcompare buy us over rpm-vercomp? Not retorting, just curious. I'd be inclined to use rpm-vercomp given that we can tweak it however we like if we so need.

...

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.

OK, so, due to popular demand I'm gonna push the next release as MacPorts 1.5.2 ;-) And I'm figuring it'll be tomorrow, given that some users are quite desperate about the mtree violations errors and not much else has been said about it here.

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.

We will definitely need a migration path for selfupdating users once we move to proper version numbers in trunk, but I don't think moving the version number file around will be a requirement. We could, for example, code up the feature in trunk and release it as 1.6 (floating point just as 1.520), which current installations would pick up (plain mathematical comparison, so remember that 1.6 > 1.5999999999999999). We would then release 1.6.1 (proper version number) and have at-that-moment existing installations also pick it up 'cause {rpm-vercomp | vcompare} already in them would recognize 1 == 1, 6 == 6 and NULL < 1. That of course leaves the question of straggles (who'll attempt a direct move from 1.520 to 1.6.1) open, so I guess my strategy could also see some improvements In any case, I'm just brain storming over this whole thing and not even proposing we move straight from 1.520 up to 1.6.0 (properly named). If it happens, great! But in any case it's not something I'm requesting ;-) We need a proper migration path first so lets get it together before we attempt anything. Ideas?

Chris

Regards,... -jmpp