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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
