1.0-beta.28-ea.0 ... early access for symbolicVersions and friends

To load 1.0-beta.28-ea.0:

  Gofer new
        gemsource: 'metacello';
        package: 'ConfigurationOfMetacello';
        load.

Then:

  (ConfigurationOfMetacello project version: '1.0-beta.28-ea.0') load.

Once you've loaded 1.0-beta.28-ea.0, you'll be able to load newer
early access versions using this expression, using the symbolicVersion
#earlyAccess:

  (ConfigurationOfMetacello project version: #earlyAccess) load.

MetacelloSymbolicVersionExample1Config is a config with symbolic
versions defined for #development and #stable, while using the default
definition for #bleedingEdge. MetacelloSymbolicVersionExample1Config
is a subclass of MetacelloBaseConfiguration (yes an abstract
configuration class) that is in the package Metacello-Base which is
intended to be loaded into core image without any other Metacello
artifacts. More on that later, but for symbolic versions, there are
three methods:

  defaultBleedingEdgeVersion, defaultDevelopmentVersion and
defaultStableVersion

which provide default implementation for the three standard symbolic
versions. Note that these are default implementations and that the
methods are not called by default - look at
MetacellBaseConfiguration>>bleedingEdge to see how the default methods
are intended to be used.

You can override the definition of bleedingEdge in your own
configuration (whether or not you have subclassed
MetacellBaseConfiguration) and you can choose to throw an error. Note
that the #bleedingEdge message is sent during the construction phase
of the versionSpec.

MetacelloSymbolicVersionExample2Config  is a config that uses the
#bleedingEdge version of MetacelloSymbolicVersionExample1Config  in
the '1.0-baseline' version.

You can also look at ConfigurationOfMetacello>>earlyAccess: for an
example of defining a symbolicVersion.

If you look at the default attributes:

  ConfigurationOfMetacello project attributes

You will see that in 1.1 image the following standard attributes are
defined:

  #(#common #squeakCommon #pharo #'pharo1.x' #'pharo1.1.x')

In a 1.0 you'll have #'pharo1.0.x' instead of #'pharo1.1.x' and so on.
Symbolic versions can then be defined for each of the Pharo versions
that are running around.

I encourage you to take a look at your own configurations and see how
you would use symbolic versions ... don't commit any configurations to
a shared repository ... if you want to experiment, you can copy your
config and packages (and any configs that your config references) to a
local directory repository where you can  change the configs to your
hearts content (adapt the second script on this page
http://code.google.com/p/metacello/wiki/MaintainingSecondaryRepository).

I have also added support for validating a configuration. Use the
following to run the validation:

  MetacelloMCVersionValidator validateConfiguration:
ConfigurationOfMetacello

and inspect the results ... you'll get an OrderedCollection of
validation issues.

I ran a validation against the 90 some configurations in the
MetacelloRepository and it turns out that about 30 of them have no
version defined for some combination of packages/projects which made
me think that for a little while at least, we'll have to support some
kind of default when the versionString is missing for a project or
package ... for a project the default in this version is the
#bleedingEdge version (see
MetacelloBaseConfiguration>>defaultBleedingEdge for the
implementation). Now that I've changed to use a default (and changed
the validator) the validator is only complaining about 13 configs with
about half of those showing real issues. I haven't fixed the issues
(yet) because I'd like to leave the problems there for others to
analyse ...

Here's a sample critical warning for ConfigurationOfJQueryWidgetBox:

  Critical Warning: The name of package 'JQWidgetBox-UILayou-Core'
does not match
    the file name 'JQWidgetBox-UILayout-Core-obi.2' in version '1.3'
    [ packageNameMismatch ]

In this case you can see that there is a typo in the package name ...
there is a reasonCode associated with each notification (in this case
#packageNameMismatch) and at the moment the issues are divided into
Errors, Critical Warnings, and Warnings.

This is early access, so I'm still in the process of fine tuning some
things and writing tests and examples/docs, but of course I'm
interested in feedback and bug reports ... I've already started work
on 1.0-beta.28-ea.1.

Here's the full description of work done since 1.0-beta.27.4:

- pick up #versionKey from work done with Simon during ESUG 2010
- add MetacelloPlatform>>primeStackCacheWith:doing: from work done
with Simon during ESUG 2010
- deprecate
MetacelloPlatform>>primeStackCacheFor:doing:defaultDictionary:
- add primeStackCache tests
- dynamic caching for 5x speedup of #currentVersion
- standard Pharo version attributes: #''pharo1.x'', #''pharo1.0.x'',
#''pharo1.1.x'', #''pharo1.2.x''
- throw an error when a version is not found
- collapse running zeroes in a version number in absence of a numeric
element
- integrated changes from 1.0-beta.27.5
- introduce MetacelloBaseConfiguration added so that Configurations
can have a superclass (or not)
- introduce symbolic versions.
  - #development, #stable, and #bleedingEdge are standard versions.
  - a default is defined for each of them in the abstract
configuration
- if versionString not defined for project reference, #bleedingEdge
version is used as the default (instead of latest version)
- stop using #lastMetacelloVersionLoad altogether
- add Configuration validation

At this point things can change pretty dramatically so be prepared for
the possibility...

Dale

Yeah, Metacello-Base is intended for just that purpose, but I want to
wait a bit until things get finalized...I would hope that it would be
integrated into Pharo, Squeak, and GemStone.

Dale

On Nov 4, 7:33 pm, Mariano Martinez Peck <[hidden email]>
wrote:

I've just released 1.0-beta28-ea.1. Fixed a bug, tweaked the
validation code, and added symbolicVersion support to OB-Metacello.

ConfigurationOfMetacello has 3 symbolicVersions explicitly defined and
#bleedingEdge is defined by default:

  #stable              - 1.0-beta.27.5
  #earlyAccess    - 1.0-beta.28-ea.1
  #development  - 1.0-beta.28

After updating to 1.0-beta28-ea.1 with:

  (ConfigurationOfMetacello project version: #earlyAccess) load

If you want to see the new OB-Metacello support do the following:

  (ConfigurationOfMetacello project version: #earlyAccess) load: 'UI'

Here's the complete list of changes:

- clean up undefined symbols refs in Metacello-Base
- adjust validation to provide warning when no version is specified
- differentiate between versions not specified, but resolved and
versions not resolved in validation
- validation for duplicate attribute blocks
- fix Issue 100: http://code.google.com/p/metacello/issues/detail?id=100
"last block wins when there are duplicate attribute blocks"
- add symbolic versions to version chooser in OB-Metacello
- recursive validation option
- extended validation to restrict recursive validation of a particular
version

Dale

On Nov 4, 9:35 pm, Dale <[hidden email]> wrote:

1.0-beta.28-ea.2 is now available ... use pragma for default
symbolicVersion methods:

  bleedingEdge
        <defaultSymbolicVersion: #bleedingEdge>

        ^self defaultBleedingEdgeVersion

The pragma makes it possible to identify and define all
#symbolicVersions during project construction so the version specs are
complete.

Renamed OB-Metacello menu items to use Configuration instead of
Project.

Added OB-Metacello commands for validating a Configuration ... get
back list of critical issues (errors and critical warnings). Can also
validate a specific version ... use the version validation if you get
an error or unexpected results when using a Configuration to help spot
where the real issue might be hiding.

Dale

On Nov 5, 10:49 am, Dale <[hidden email]> wrote:

1.0-beta.28-ea.3 is available:

- add MetacelloMCVersion>>difference: for getting differences between
two versions ... primarily listing added/removed/modified mcz files
and project version strings.
- add loop detection to validation
- stop using deprecated in Pharo1.2 methods (sortBy:)
- Metacello Tool box

5 tests are failing, but they are due to a change in output format
only...but hey it's Friday night:)

Dale

On Nov 8, 12:06 pm, Dale <[hidden email]> wrote: