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 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,...


-jmpp