version archival...pruning versions...configuration branching

I've spent some time this morning thinking about things and then spent
some time this afternoon talking some ideas over with James and I'd like
to make a proposal that I think might just solve several problems at once:

   - stableVersion, developmentVersion, bleedingEdgeVersion
   - 'default' version convention
   - Metacello Universes and version pruning
   - MetacelloRepositoryForPharo1.x


I'll throw the idea out here and then we can thrash/trash/refine the
idea during ESUG...

The first part of the idea is that the three messages (stableVersion,
developmentVersion, bleedingEdgeVersion) should be explicitly
implemented on the class _and_ instance side of a Metacello class.

The second part of the idea is that instead of implementing the methods
in MetacelloProject (the traditional solution), that we implement the
methods on the instance side of the Metacello configuration.

The stableVersion instance side method would be implemented like the
following:

   stableVersion

     ^self project version: '1.0-beta.27.4'

and the bleedingEdgeVersion method would look like:

   bleedingEdgeVersion

     ^self project version: '1.0-beta.27-baseline'

... so we have an explicit declaration for each of the versions:
stableVersion, developmentVersion, bleedingEdgeVersion.

The implication is that in different versions of the mcz file containing
the configuration, those methods _be implemented differently_!

I'm imagining that in the Pharo1.2 repository the
ConfigurationOfMetacello will implement the two methods as described above:

   stableVersion

     ^self project version: '1.0-beta.27.4'

and

   bleedingEdgeVersion

     ^self project version: '1.0-beta.27-baseline'

While in the Pharo 1.1 repository, the methods could be different:

   stableVersion

     ^self project version: '1.0-beta.26'

and

   bleedingEdgeVersion

     ^self project version: '1.0-beta.26-baseline'

and so on ... So we have three methods that might be different from
version to version of the mcz file containing the configuration, but the
actual specification of each of the versions remains unchanged and there
is no need to prune version specifications to clarify which version or
versions are applicable in a particular Pharo image (which is what would
be necessary if we were to continue to use the notion of latest version,
etc.)...

I'd mentioned before the idea of using a selector in place of the
version string for a project reference where we'd replace an expression
like this (in a version spec):

   spec project: 'Metacello Core' with: '1.0-beta.26'.

with this:

   spec project: 'Metacello Core' with: #stableVersion.

Which would be implemented by sending the message #stableVersion to the
configuration and using the above example would version '1.0-beta.27.4'
in Pharo 1.2 and version '1.0-beta.26' in Pharo 1.1...

We still have the issue of clutter due to a large number of version
methods. If we use a subclass of the ConfigurationOf class (called
ArchiveOf) to actually hold all of the version/baseline methods (I do
mean all) then they would be completely hidden from the casual user.
The ConfigurationOf class would contain basically the three methods
mentioned above, but for 99% of the users that is the only decision that
they need to make ... do I want to load the
stable/development/bleedingEdge of the configuration ...

The rationale for 'archiving' versions instead of 'pruning' them is that
we lose information when we prune. There might be valid configurations
that reference a version that may have been pruned ... by archiving the
old versions the version information isn't lost and in fact all branches
of ConfigurationOf _package_ could be kept in synch in terms of the
ArchiveOf class and would only differ in the implementation of the three
  magic version methods.

There are rough edges around this idea and there are probably details to
be worked out, but there are also advantages to the approach ... and of
course perhaps this will spur some more creativity for solving the
problems ...

I'm interested in the feedback/fallout/discussions...

Dale