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

[Juan Manuel Palacios]

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