Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0

[Bryan Blackburn]

On Mon, Dec 08, 2008 at 05:42:55PM -0430, Juan Manuel Palacios said:
>
> On Dec 8, 2008, at 5:22 PM, Ryan Schmidt wrote:
>
>> Definitely in favor of getting rid of the odd floating point version  
>> numbers of MacPorts proper, especially since the version numbers of all 
>> the software installed by MacPorts are assumed to be dotted decimal 
>> numbers. (That of course needs to be fixed too, for the perl ports and 
>> perhaps others that are released on a floating point version numbering 
>> scheme [1].)
>>
>> However, we have already cut 1.7.0-rc1 and it contains a year's worth of 
>> great changes. I don't want to delay it any further, unless to fix 
>> critical bugs, which this isn't. Let's put this in 1.8.0. There's no 
>> reason we can't release 1.8.0 very soon after 1.7.0.
>>
>
> 	Funny enough, if I hadn't changed selfupdate to use rpm-vercomp in  
> r32364, we could release 1.7 (rather than 1.700) and fix the problem  
> right now, since mathematically  1.7 > 1.610; these new sources would  
> then carry the switch to rpm-vercomp and thus take care of 1.7.1 or 1.8.0 
> > 1.7. All I can say about that is a big "UUUPPSSS!".

Note that there will definitely be some people who don't upgrade right away,
so they may not see the fix in 1.7.0.  So the issue is going to come up
regardless, and the best way to deal with it is probably to just have them
install from the current DMG.

>
> 	But well, after whining about what would have been better, I'll await  
> your green light to include the extremely lame special-case hack to move 
> trunk away from floating point version numbers, by manipulating 1.800 into 
> 1.8.0, unless a better approach is devised. Following that, I'll commit 
> the patch I sent originally.

It can go into trunk since that's been 1.8 for over a week now...

Bryan


>
> 	Regards,...
>
> -jmpp
>