currentVersion cleanup

Last weekend I discovered an infinite loop in the currentVersion/findCurrentVersion algorithm in Metacello. The loop was triggered by an odd set of circumstances, nonetheless, infinite loops are not cool.

Doru, you've heard me several times tell you that the currentVersion algorithm wasn't completely stable and the infinite loop was the proof setting smack dab in the middle of the pudding.

I've spent the last week putting together test cases and cleaning up the currentVersion algorithm  to the point where I now feel that it is finally deterministic.

In the process I have deleted about 20 methods and so I want to publish the list before I publish the version in case any of you are depending upon any of them (I know that Simon and Doru have been writing tools against Metacello). I've centralized the currentVersion calculation to a single method and the following methods became expendable in 1.0-beta.23 and I nuked them:
  - MetacelloVersion>>isCurrentCovering:
  - MetacelloProject>>currentVersionComparison:to:covering:
  - MetacelloProject>>currentVersionCovering:
  - MetacelloProject>>findCurrentVersion
  - MetacelloMCVersionSpec>>isCurrentCovering:
  - MetacelloMCVersionSpec>>isPartiallyCurrentAgainst:
  - MetacelloMCProjectSpec>>isCurrent
  - MetacelloProjectReferenceSpec>>compareVersionForLoad:using:
  - MetacelloAbstractPackageSpec>>compareVersionForLoad:using:
  - MetacelloMCVersionSpec>>isPartiallyCurrentFor:
  - MetacelloProjectReferenceSpec>>isPartiallyCurrentUsing:
  - MetacelloMCProjectSpec>>comparePartialVersion:using:
  - MetacelloProject>>partialVersionComparison:to:covering:
  - MetacelloMCProject>>projectPackage
  - MetacelloMCVersionSpec>>currentVersionComparison:covering:
  - MetacelloMCVersion>>currentVersionComparison:covering:
  - MetacelloVersion>>currentVersionComparison:covering:
  - MetacelloProjectReferenceSpec>>isPartiallyCurrentUsing:
  - MetacelloMCProjectSpec>>compareVersionForLoad:using:

If you are using one or more of these methods let me know as it is very likely that there is another method with equivalent functionality the you can probably use. If you're not sure, you could load 1.0-beta.23 and test your code, but keep in mind that I plan to push around some more code and add a couple of more methods before I'm done, so check with me first about a suitable replacement method.

Once I'm "done" I plan to load a bunch of configurations (Seaside, Moose, and Pharo) to ensure that they continue to function (I'm up to 200 unit tests, but you can't be too careful:). I also plan to take Metaceller through it's paces - I've found Metaceller a very useful tool for getting a picture of the loaded configurations....

If you want learn a little bit more about what I have been up to, read on:

CurrentVersion is an attempt to look at the packages that are currently loaded in an image and determine what version of the configuration best applies. Since it is valid to load only parts of a configuration, the calculation can get hairy.

In the end I was able to simplify everything by qualifying the currentVersion answer with a #versionStatus that provides explicit information about the meaning of the currentVersion:

  #allLoadedToSpec        all projects and packages are loaded and match
                            specification
  #loadedToSpec           all loaded projects and packages match specifications
  #loadedMatchConstraints all loaded projects and packages match constraints

"match specification" means that the package or project exactly matches the configuration.
"match constraints" means that the package or project versions are >= (typically) the versions specified in the specification

So #versionStatus has basically eliminated the need for all of the above methods and in fact provides high quality information about the loaded status of the version.

I will also probably be including something like the following three versionStatus states:

  #singleSpecMatch       at least one loaded project or package matches
                           specification
  #singleSpecConstraint  at least one loaded project or package matches
                           constraints
  #singleLoaded          at least one project or package is loaded

#allLoadedToSpec, #loadedToSpec, #loadedMatchConstraints are guaranteed to exist and I'm trying to decide on whether the last three are useful. At a minimum I'll include #singleLoaded - I may change the name to #SWAG because that's really what it is:)

Dale

Hi Dale

thanks for the heads-up. I only use two methods related to this: currentVersion and clearCurrentVersionCache. So it should not be a problem.


On 5 févr. 2010, at 19:36, Dale Henrichs wrote:

--
 Simon

Simon,

Good, keep in mind that may want to check the versionStatus of the currentVersion when you start using 1.0-beta.23. The SWAG guy might mess you up.

Also, I've fixed the sticky currentVersion cache bug in 1.0-beta.23, so you won't need #clearCurrentVersionCache either.

Dale
----- "Simon Denier" <[hidden email]> wrote:

| Hi Dale
|
| thanks for the heads-up. I only use two methods related to this:
| currentVersion and clearCurrentVersionCache. So it should not be a
| problem.
|
|
| On 5 févr. 2010, at 19:36, Dale Henrichs wrote:
|
| > Last weekend I discovered an infinite loop in the
| currentVersion/findCurrentVersion algorithm in Metacello. The loop was
| triggered by an odd set of circumstances, nonetheless, infinite loops
| are not cool.
| >
| > Doru, you've heard me several times tell you that the currentVersion
| algorithm wasn't completely stable and the infinite loop was the proof
| setting smack dab in the middle of the pudding.
| >
| > I've spent the last week putting together test cases and cleaning up
| the currentVersion algorithm  to the point where I now feel that it is
| finally deterministic.
| >
| > In the process I have deleted about 20 methods and so I want to
| publish the list before I publish the version in case any of you are
| depending upon any of them (I know that Simon and Doru have been
| writing tools against Metacello). I've centralized the currentVersion
| calculation to a single method and the following methods became
| expendable in 1.0-beta.23 and I nuked them:
| >  - MetacelloVersion>>isCurrentCovering:
| >  - MetacelloProject>>currentVersionComparison:to:covering:
| >  - MetacelloProject>>currentVersionCovering:
| >  - MetacelloProject>>findCurrentVersion
| >  - MetacelloMCVersionSpec>>isCurrentCovering:
| >  - MetacelloMCVersionSpec>>isPartiallyCurrentAgainst:
| >  - MetacelloMCProjectSpec>>isCurrent
| >  - MetacelloProjectReferenceSpec>>compareVersionForLoad:using:
| >  - MetacelloAbstractPackageSpec>>compareVersionForLoad:using:
| >  - MetacelloMCVersionSpec>>isPartiallyCurrentFor:
| >  - MetacelloProjectReferenceSpec>>isPartiallyCurrentUsing:
| >  - MetacelloMCProjectSpec>>comparePartialVersion:using:
| >  - MetacelloProject>>partialVersionComparison:to:covering:
| >  - MetacelloMCProject>>projectPackage
| >  - MetacelloMCVersionSpec>>currentVersionComparison:covering:
| >  - MetacelloMCVersion>>currentVersionComparison:covering:
| >  - MetacelloVersion>>currentVersionComparison:covering:
| >  - MetacelloProjectReferenceSpec>>isPartiallyCurrentUsing:
| >  - MetacelloMCProjectSpec>>compareVersionForLoad:using:
| >
| > If you are using one or more of these methods let me know as it is
| very likely that there is another method with equivalent functionality
| the you can probably use. If you're not sure, you could load
| 1.0-beta.23 and test your code, but keep in mind that I plan to push
| around some more code and add a couple of more methods before I'm
| done, so check with me first about a suitable replacement method.
| >
| > Once I'm "done" I plan to load a bunch of configurations (Seaside,
| Moose, and Pharo) to ensure that they continue to function (I'm up to
| 200 unit tests, but you can't be too careful:). I also plan to take
| Metaceller through it's paces - I've found Metaceller a very useful
| tool for getting a picture of the loaded configurations....
| >
| > If you want learn a little bit more about what I have been up to,
| read on:
| >
| > CurrentVersion is an attempt to look at the packages that are
| currently loaded in an image and determine what version of the
| configuration best applies. Since it is valid to load only parts of a
| configuration, the calculation can get hairy.
| >
| > In the end I was able to simplify everything by qualifying the
| currentVersion answer with a #versionStatus that provides explicit
| information about the meaning of the currentVersion:
| >
| >  #allLoadedToSpec        all projects and packages are loaded and
| match
| >                            specification
| >  #loadedToSpec           all loaded projects and packages match
| specifications
| >  #loadedMatchConstraints all loaded projects and packages match
| constraints
| >
| > "match specification" means that the package or project exactly
| matches the configuration.
| > "match constraints" means that the package or project versions are
| >= (typically) the versions specified in the specification
| >
| > So #versionStatus has basically eliminated the need for all of the
| above methods and in fact provides high quality information about the
| loaded status of the version.
| >
| > I will also probably be including something like the following three
| versionStatus states:
| >
| >  #singleSpecMatch       at least one loaded project or package
| matches
| >                           specification
| >  #singleSpecConstraint  at least one loaded project or package
| matches
| >                           constraints
| >  #singleLoaded          at least one project or package is loaded
| >
| > #allLoadedToSpec, #loadedToSpec, #loadedMatchConstraints are
| guaranteed to exist and I'm trying to decide on whether the last three
| are useful. At a minimum I'll include #singleLoaded - I may change the
| name to #SWAG because that's really what it is:)
| >
| > Dale
|
| --
|  Simon