Changeset 43571


Ignore:
Timestamp:
Dec 12, 2008, 3:11:11 AM (12 years ago)
Author:
jmpp@…
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).
  1. 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@).
  1. 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,
added to what was done up until r43375, 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 functional, but don't be shy to pull
my ear if I again got it wrong!

Location:
trunk/base
Files:
1 added
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/base/src/macports1.0/macports.tcl

    r43375 r43571  
    18791879    }
    18801880
    1881     # Temporary special-case hack to move MacPorts away from floating point version numbers:
    1882     # If we encounter a floating point version number smaller or equal to 1.800, we force the
    1883     # upgrade, since the 8 in 1.8.x will always be smaller than, e.g. the 700 in 1.700, the 610
    1884     # in 1.610, etc, and therefore the upgrade would never trigger on its own.
    1885     if {$macports::autoconf::macports_version <= 1.800} {
    1886         set use_the_force_luke yes
    1887     }
    1888 
    18891881    # check if we we need to rebuild base
    18901882    if {$use_the_force_luke == "yes" || [rpm-vercomp $macports_version_new $macports::autoconf::macports_version] > 0} {
Note: See TracChangeset for help on using the changeset viewer.