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

[Juan Manuel Palacios]

On Dec 7, 2008, at 3:42 PM, Juan Manuel Palacios wrote:

>
> 	A while ago I did most of the needed work to move MacPorts to a  
> more standard version number formatting, that is x.y.z, both for its  
> internal workings (e.g. selfupdate) and for the UI. If I'm not  
> mistaken, most of that code has not been released to the public yet,  
> which is why the change can't just be pushed onto people in a single  
> release because of the way version numbers used to be compared  
> previously (simple mathematical comparison, through which, e.g.,  
> 1.610 > 1.7.0). Once 1.7.0 is released, the code I wrote (in base/ 
> src/macports/macports.tcl, proc macports::selfupdate) will be in  
> people's hands and a comparison between 1.700 Vs. 1.7.1 will work  
> positively either through rpm-vercomp or a simple forcing of the  
> selfupdate.
>
> 	Therefore I propose MacPorts name its next release after 1.7.0  
> (1.700) either 1.7.1 or 1.8.0, but in any case in the more standard  
> x.y.z formatting. Attached is a patch to finish this work, which  
> should *NOT* be applied to the 1.7.0 (1.700) release. It's been  
> quite a while since I made the first round of changes, so there's a  
> chance this fresh patch is incomplete in some way (admittedly, I  
> haven't tested it yet). So please review and complete if needed.
>
> 	I'd appreciated it if release engineering considered this work for  
> inclusion in trunk/release_1_7, thanks!
>
> 	Regards,...
>
>
> -jmpp
>
> <macports_x.y.z_version.diff>


	Two things I forgot to mention:

1) An autoreconf would be needed after modifying the configure.ac file;
2) The base/config/mp_version file could be safely deleted if my work  
is indeed complete;

	Do let me know if I'm missing anything, thanks!


-jmpp