MacPorts 1.5.11 (Fwd: [27780] branches/release_1_5/base)

[Chris Pickel]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070814/ef3c2fc5/PGP.bin