On 22 Mar 2014, at 23:06, Pharo4Stef <[email protected]> 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
