On 22 Mar 2014, at 23:06, Pharo4Stef <pharo4Stef@free.fr> wrote:
Now others told me that in other community this is the inverse. People only refer to the catalog.
Yes, that is perfect if there is one catalog for the community. Not a different catalog per version of the platform (pharo2.x, pharo3.x,...). A metacello configuration itself has sufficient methods to specify correctly how to load on which platform. If you make a single meta repository, you can check if the configuration has a #stable version for the platform and show that in the configuration browser. Now, I *know* that people make mistakes and that they can screw up a configuration in the future and that you want to protect yourself from that by making different catalogs such that they are frozen. But I really think this actually makes matters more complicated (i.e. the reason for this thread). To make a snapshot (e.g. for Pharo3.0), you can reference the specific version of a configuration (using the #file: message) to protect yourself from someone messing up in a future version of the configuration. This is what I do to protect my own projects from suddenly being broken because some changed a configuration in a way that breaks it or just messes up my load procedure. It works well.
Now the question is the following one. Ideally I would like to have one inbox and that configuration move to the catalog for their version. (Because I do not see the point of having around old versions of projects that do not load in the given version).
The configuration browser can require a configuration to explicitly specify a #stable version for the platform, otherwise it does not show it as 'supported' ?
I explained that in the Pharo vision document. Now may be other solutions are better.
Version management is difficult... I guess we all have a love-hate relationship with Metacello ;-) For me, Metacello is doing a good job but the problem is that it's almost always very difficult to find out why it does something you do not expect. Tools like Metaceller help there. Since I am using, I reduced my 'configuration-fixing-time' by half. Johan