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 6:09 PM, Bryan Blackburn wrote:

> 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


	This work is now completed in r43375, at least in theory. I took care  
of testing extensively with the help of a local rsync server so I  
don't think I broke anything, but upgrading an installation can have  
so many faces that I'm keeping my eyes open. Let me know if anything  
runs afoul.

	As for the special-case hack, I chose to force the upgrade if the  
version number encountered is smaller or equal to 1.800, per the  
explanatory comment I wrote in the selfupdate proc in base/macports1.0/ 
macports.tcl.  Also, the "or equal to" extension to my original  
proposal will help us catch those who lag behind and don't jump right  
away onto 1.8.0. The question now is when to remove the hack...

	Anything I missed...? Anyone against this lame hack...? Regards,...


-jmpp