On 21 March 2013 19:23, Chris Muller <ma.chris.m at gmail.com> wrote:
>> In Metacello you define versions of a project. For each version you specify the list of mcz files that make up the version and that list is qualified by platform.
>
> Good.  Now, if only binary resources (files) could also be included in
> the package then there would be a basis for Metacello to be a serve as
> a medium of app delivery..
>
>> So each version includes a specification of which platform versions are supported.
>
> Ok, that's good, just one clarification though:  Are the declared
> platforms just #squeak, #pharo and #gemstone or actually specific
> releases of those platforms such as #squeak4dot4, #pharo1dot4,
> #pharo2dot0, etc.?
>
> The Platforms evolve just like the Packages and, as you know, bit-rot
> is one of the issues we want the catalog to avoid.  That's why the
> catalog is designed to remember the valid *combinations* of
> (Platform-Release) + (App-Release).

Yes, and yes. Metacello has platforms like #squeak but also has
platforms like #'squeak4.4'. But of course if you only say #squeak
then your users have a problem.

>> When you load version 3.0.7 of a project, you should get the same functionality without regard which platform you are using ....
>>
>> A configuration contains the entire version history for a project ... so 5 years from now, if you try to load version 3.0.7 into Squeak4.4 it will load correctly (assuming that version 3.0.7 works in Squeak4.4 today) ...
>
> So it's a fixed-configuration, that's good.  The primary catalog
> requirement is to tell the newbie:
>
>    which versions of which software packages will work on my shiny
> newly-installed Squeak 4.1?
>    (or Squeak4.4, or whatever release of Squeak he's running).
>
> I don't know whether Metacello can do that but that's why we can just
> document it in an external catalog to know.
>
>> Metacello is not magical. If developers don't maintain a configuration so that it works on all of the "supported" platforms then it will not work ... Maintenance activities for Squeak and Seaside has fallen off and the configuration for Squeak has degraded ...
>
> This is confusing language for me..  When you say "the configuration
> for Squeak has degraded" you just mean Squeak has advanced to 4.4 but
> the Seaside configuration remained fixed for Squeak 4.3 (or 4.2
> whichever), is that right?  IOW, a fixed-configuration will never
> "degrade" in terms of a legacy release of Squeak, right?  Once 3.0.7
> config works in Squeak 4.4, it will forever work in Squeak 4.4 --
> that's what you said above.  I hope so right because that's what I
> want.

I think what Dale's talking about is that there's nothing stopping
someone monkeying around with an old configuration. Specifically, your
ConfigurationOf will typically have methods like #version11:.,
#version12: and so on. These pull in baselines - abstract dependency
graphs - and add versioning info. Baselines are often shared, because
the rate of change of the dependency graph is usually very much lower
than the rate of change in version numbers. But there's nothing
stopping someone writing a ConfigurationOf that's not pinned to a
platform version - Squeak 4.4, rather than "generic Squeak" - or from
altering #version11: while ostensibly preparing #version13:. You
really, really shouldn't do that kind of thing, but it's possible, so
people do make these kinds of changes (whether intended or by
accident).

>> Tobias has picked up the ball and is getting Seaside running on the newer versions of Squeak and as he figures out the formula, he records the information in the configuration ... this is how Metacello is _supposed_ to work:
>>
>>   Developers with expertise on how things get loaded specify the dependencies
>>   and load order in a configuration for others to use.
>
> Great, so Tobias please let me know when it's ready to go one-click in
> the catalog without needing those two orphan versions manually loaded
> first.

frank