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

[Ryan Schmidt]

On Dec 8, 2008, at 01:02, Juan Manuel Palacios wrote:

> On Dec 7, 2008, at 5:27 PM, Juan Manuel Palacios wrote:
>
>> 	The way I see it (unless I'm brain dead at the moment and missing  
>> something incredibly obvious, or completely misunderstanding the  
>> way rpm-vercomp works), the real problem is in the contents of  
>> both files:
>>
>> -) mp_version contains 1.610 in the release_1_6 branch (what  
>> regular uses currently have), 1.700 in the release_1_7 branch  
>> (what will be released next);
>> -) macports_version contains 1.6.1 and 1.7.0, respectively;
>> -) in both 1.610 and 1.700, the necessity to rebuild base in a  
>> selfupdate run is as follows;
>>
>> from base/src/macprots1.0/macports.tcl:
>> if {$use_the_force_luke == "yes" || [rpm-vercomp  
>> $macports_version_new $macports::autoconf::macports_version] > 0} {
>>
>> and $macports::autoconf::macports_version comes from base/src/ 
>> macports1.0/macports_autoconf.tcl.in:
>> 36     variable macports_version "@MP_VERSION@"
>>
>> and @MP_VERSION@, in turn, is determined from base/config/ 
>> mp_version in base/configure.ac:
>> 15 # Read the old, floating point format version, which we still  
>> use internally, and export it for the  
>> $macports::autoconf::macports_version variable
>> 16 MP_VERSION=$(cat config/mp_version | tr -d '\n')
>> 17 AC_SUBST(MP_VERSION)
>>
>> 	So the real problem is determining when switching  
>> $macports::autoconf::macports_version from @MP_VERSION@ to  
>> @MACPORTS_VERSION@, the latter being determined from base/config/ 
>> macports_version, is appropriate. If done for 1.7.0, users'  
>> installations will be doing an rpm-vercom of 1.610.0 against  
>> 1.7.0, which will obviously fail. If we do it by 1.7.0, then it'll  
>> be 1.700.0 against 1.7.1, and I'm unsure of the result (though my  
>> guess is 1.7.1 < 1.700.0, which would also fail). Answering this  
>> question would clear the way to apply the patch I attached here  
>> originally (cf. my last comment in r32364).
>
>
> 	I played with rpm-vercomp for a while and confirmed that 1.7.1  
> would not be seen as newer than 1.700, as I expected; on the other  
> hand, the only way for users to selfupdate at present, other than  
> forcing, is for the new release to be called 1.700, as currently  
> planned, since 1.7 < 1.610 and 1.7.0 < 1.610. So as you can easily  
> see, all we would be doing is pushing the problem one-more-release  
> away by carrying on with floating point numbers until something  
> else is done.
>
> 	So, if we want to solve the problem, if we consider it a problem  
> in the first place (do count me in with those who consider floating  
> point version numbers a little odd), I see no other solution but to  
> special-case the selfupdate proc that's soon to be released with  
> 1.700:
>
> Index: macports.tcl
> ===================================================================
> --- macports.tcl	(revision 43285)
> +++ macports.tcl	(working copy)
> @@ -1876,6 +1876,10 @@
>      # get downloaded MacPorts version
>      gets $fd macports_version_new
>      close $fd
> +    # Temporary and lame special-case to move away from floating  
> point version numbers:
> +    if { $macports_version_new == "1.700" } {
> +        set $macports_version_new "1.7.0"
> +    }
>      # echo downloaded MacPorts version
>      ui_msg "Downloaded MacPorts base version $macports_version_new"
>
>
> 	The selfupdate currently in users' hands would still do a simple  
> [rpm-vercomp 1.700 1.610] and would successfully proceed with the  
> upgrade. The special-cased selfupdate in 1.700 would then allow us  
> to release 1.7.1 or 1.8.0 and finally move away from floating point  
> version numbers by performing a manipulated [rpm-vercomp 1.7.0 1.7.1].
>
> 	We could also, of course, choose to stick with floating point  
> version numbers forever more, but those being a tad odd is the  
> whole point of this thread ;-) Or we could also instruct users to  
> force...
>
> 	Opinions? Regards,...

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.


[1] http://trac.macports.org/ticket/11873