the future of #stable in Metacello

I've cross-posted to pharo and metacello mailing list ... I'd prefer that the ongoing (possibly gory discussion:) take place on the metacello list, but since symbolic versions have been discussed on the pharo list it might make sense to keep the discussion in the pharo list ...

First a bit of background.

Symbolic versions were introduced because we were facing a situation where developers were breaking projects that were working fine in Pharo1.3 while porting them to Pharo1.4 and breaking Pharo1.4 behavior while fixing bugs in Pharo1.3 ...

Metacello was pretty new then and an attempt was being made to have folks use Pharo1.4 while it was still in development and there were enough changes in Pharo1.4 that some code would break in Pharo1.4 while working in Pharo1.3 ... The real problem though was that project dependencies became difficult to manage in a number of different dimensions:

  - projects would change existing versions to work on
    the new platform version and break the old platform
    version
  - projects would create a new version that would run on
    both platforms, so dependent projects would to depend
    pon a new version
  - projects would create a new version that would run on
    only one platform, so dependent projects would have to
    depend upon 2 different versions based on platform
    version

These types of things in isolation would be manageable, but the rate of change was high and changes propogated faster than configuration managers could keep up with. Oh and don't forget the projects where the maintainers were not even using Metacello at all and a third party developer had to translate the projects changes to a configuration to keep things working...

Symbolic versions were introduced as a stopgap measure that made it possible for folks to easily declare which versions of the project were intended to be used on a particular platform. Dependent projects could depend upon the #stable version and the whole dependency management universe became simpler. Symbolic versions made it practical to port code to Pharo1.4 without impacting Pharo1.3 and so on.

Which brings us to the present and a slightly different situation, but first let's step back a bit and look at what we have in Metacello today.

In Metacello, a version is a label applied to a specific collection of mcz files. The collection of mcz files may be different depending upon which platform you happen to be loading the project into, but in the end, the same version on different platforms should give one the same set of functionality.

Once a version has been released (indicated by a #release blessing) the contents of that collection of mcz files should never change ... If a change _is_ made, once should create a new version of the project to reflect that something has changed.

In Metacello there are platform attributes (i.e., #'pharo1.x', #'pharo1.4.x', #'pharo1.4.1.x', #'pharo2.x', etc.). The platform attributes can provide very fine-grained control over which mcz files need to be loaded into a particular version of a platform, but the mechanism only works if the underlying platform is consistently naming versions ...

In Metacello symbolic versions are simply a tagging mechanism. Versions and symbolic versions can be used interchangeably. Any name/platform/version combination can be created.

We have been using the #stable convention for several years and it is definitely time to revisit it's use. However, we cannot drop the #stable convention without replacing it with another convention... otherwise we risk chaos, again:)

In Metacello one can specify dependencies in terms of specific version numbers (tight coupling) or a tag (very loose coupling). Allowing one to specify dependencies based on version ranges would provide an intermediate coupling that avoids the tight coupling of specific version numbers while avoiding the ambiguity of a convention based on the name of a tag (symbolic version).

If we introduce version range dependencies then individual projects can use a variety symbolic version names to properly represent their desired semantics.

If we introduce version range dependencies then we must adopt a convention for how versions are named and that convention must be used pretty consistently within the community otherwise we may just have to return to the world of using #stable in self defense again ...

As an alternative to a version numbering convention like Semantic Versioning[1], we could adopt a convention defining the semantics of a collection of symbolic version names ....

I am a fan of Semantic Versioning, but it has some pretty specific rules that "must" be followed and all projects including the Smalltalk platforms (GemStone, Pharo and Squeak). Scan through the discussions surrounding Semantic Versions[2] to see what I'm talking about...

In the grand scheme of things I don't want Metacello to be locked into any one convention. I am willing to have Metacello to support multiple conventions if called for.

I have support for the Semantic Versioning version numbering scheme in Metacello, but other schemes can be added. I have anticipated the need to support version number ranges and have already built in a certain level of support and am willing to expand the capabilities in this area as needed ...

Whatever the convention is, it has to be ADOPTED and SUPPORTED by the community. Metacello cannot enforce conventions, it can only support conventions ...

So in closing, I would say that the future of #stable is in your hands...

Dale

[1] http://semver.org/
[2] https://github.com/mojombo/semver/issues