We want to use Metacello to manage smalltalk dependencies in a way that
results in working software using a minimum amount of manual work. At
the moment there are several ways in which Metacello is used, some of
which result in more work and instability than others.
An inherent conflict in managing these dependencies is the level of
repeatability that is wanted and achievable, vs. the amount of manual
work needed. On the one hand we would like perfect repeatability. That
needs an exact description of the order in which specific versions of
packages were loaded in a specific image. In Metacello, we can achieve
this by making sure all package versions are fixed and the dependencies
are fixed to numeric versions.
The problem with this is that that not necessarily results in working
software. There are several reasons for this:
- Metacello only manages the smalltalk level dependencies. It does not
take into account changes in the vm necessitating image-level changes or
operating system and library changes.
- The image itself is not fully managed with Metacello (yet). Bug fixes
made after the creation of the Metacello version might be needed for the
software to work.
- Bugs might have been found and fixed in dependencies.
In the situation of a top-level configuration, i.e. one that no other
configuration depends on, this might be acceptable. Metacello
dependencies are defined one-directional. A configuration knows on which
configuration it depends, not which configurations depend on it.
Configurations that are published should therefore always be regarded as
possibly being used by others, and not only top-level.
If we consider the situation where others (B) are depending on
configurations (A) that are written like this, then the situation gets
worse:
- B might need an update because it is affected by an issue that does
not affect A.
- B might need a different load ordering, e.g. need to only partially
load dependencies of A, then something itself and then the other
dependencies of A.
Nevertheless, sometimes we need near-perfect repeatability. For that, a
snapshot of all loaded packages provides a reasonable alternative to a
Metacello configuration version.
On the other hand the least amount of manual updates results from always
depending on #development or #stable versions of dependencies. This
results in the following problems:
- If the API of a dependency changes, the configuration might break
silently.
- Projects might be slow to promote versions from #bleedingEdge to
#development to #stable, resulting in a slow uptake of improvements.
For configurations of simple packages that have an API that is very
stable or only expands, depending on #stable can be appropriate.
From a modularity point of view, a configuration should be specific on
the packages in its own span of control, and as generous as possible in
what it accepts from its dependencies. In that way a high cohesion and
low coupling is achieved. We can achieve that by defining symbolic
versions that reflect observable change in behaviour. If we make changes
that should not affect users of the configuration, we create a new
numeric version and update the symbolic version in place to use this new
version. By default we only depend on these symbolic versions.
Stephan
