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

[Juan Manuel Palacios]

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!".

	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.

	Regards,...

-jmpp