[43571] trunk/base

[jmpp at macports.org]

Revision: 43571
          http://trac.macports.org/changeset/43571
Author:   jmpp at macports.org
Date:     2008-12-11 19:11:11 -0800 (Thu, 11 Dec 2008)
Log Message:
-----------
Revert part of r43375, as my understanding of the floating point to x.y.z transition was indeed a bit flawed.
@MP_VERSION@ and base/config/mp_version being in the old floating point format, and @MACPORTS_VERSION@ and
base/config/macports_version being their x.y.z counterparts, the correct analysis goes as follows:

 1. 1.700 and previous clients need to read the floating point version number in newer releases,
 as otherwise they'll be comparing, e.g., 1.700 vs. 1.8.0, which will fail to trigger any upgrade.
 Therefore, revive the base/config/mp_version file for it to exist in svn && rsync, which is all that's
 needed to get selfupdate working for old clients again (given that they prefer that file over
 config/base/macports_version).

 2. Remove the special-case hack in macports::selfupdate, since base/config/mp_version @ 1.800
 is enough to upgrade all 1.700 and previous clients to 1.8.x, while those in turn have no need for the
 hack at all (they'll only read base/config/macports_version while selfupdating and thus rpm-vercomp
 its contents successfully against their internal version number, i.e. @MACPORTS_VERSION@).

 3. Proposal: freeze base/config/mp_version @ 1.800, since point 1 above takes care of all pre 1.8.0
 clients across the transition and point 2 of all post 1.8.0 clients going forward (they record @MACPORTS_VERSION@,
 rather than @MP_VERSION@, as their version number and compare that against base/config/macports_version
 when selfupdating, so there will be no need to update base/config/mp_version beyond anything  greater
 than the last floating point release, i.e. 1.700).

So, from this analysis I conclude that the only thing necessary to get pre 1.8.0 clients across to 1.8.x is the existence
of base/config/mp_version in svn, and as soon as we remove it we break selfupdate backwards compatibility with them,
at which point we'll need to instruct stragglers to either force the selfupdate or install from the dmg.

PS: I've thought all this out rather extensively, so I believe this approach is mostly functional, but don't be shy to pull
my ear if I again got it wrong!

Modified Paths:
--------------
    trunk/base/src/macports1.0/macports.tcl

Added Paths:
-----------
    trunk/base/config/mp_version

Added: trunk/base/config/mp_version
===================================================================
--- trunk/base/config/mp_version	                        (rev 0)
+++ trunk/base/config/mp_version	2008-12-12 03:11:11 UTC (rev 43571)
@@ -0,0 +1 @@
+1.800


Property changes on: trunk/base/config/mp_version
___________________________________________________________________
Added: svn:eol-style
   + native

Modified: trunk/base/src/macports1.0/macports.tcl
===================================================================
--- trunk/base/src/macports1.0/macports.tcl	2008-12-12 02:55:37 UTC (rev 43570)
+++ trunk/base/src/macports1.0/macports.tcl	2008-12-12 03:11:11 UTC (rev 43571)
@@ -1878,14 +1878,6 @@
         set macports_version_new 0
     }
 
-    # Temporary special-case hack to move MacPorts away from floating point version numbers:
-    # If we encounter a floating point version number smaller or equal to 1.800, we force the
-    # upgrade, since the 8 in 1.8.x will always be smaller than, e.g. the 700 in 1.700, the 610
-    # in 1.610, etc, and therefore the upgrade would never trigger on its own.
-    if {$macports::autoconf::macports_version <= 1.800} {
-        set use_the_force_luke yes
-    }
-
     # check if we we need to rebuild base
     if {$use_the_force_luke == "yes" || [rpm-vercomp $macports_version_new $macports::autoconf::macports_version] > 0} {
         if {[info exists options(ports_selfupdate_pretend)] && $options(ports_selfupdate_pretend) == "yes"} {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-changes/attachments/20081211/914497e4/attachment.html>