On Sun, May 16, 2010 at 6:24 PM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
Mariano

I really want to have a separate folder for each version.
If this does not work then we will try something else. Why because I would like to have distribution.
Dale implemented a kind of freeze mechanism that copies all the dependent package of a project.
Then publishing to a given folder is a publication act and I like that it is explicit. It take less than a minute to copy
the given file to the 10 and 1.1 repository.

Now about you last point. Yes we need to freeze the version because loading the latest will not work and you want that people
just say load and not load: 14.2 here and load: 0.25 there. I'm correct?

Yes...imagine today you copy your Conf to Pharo10MetacelloConfiguration ... today the working version for Pharo 1.0 is� 1.4.5.
Then...you continue to develop. Of course, using the same conf. Then you have version 1.5, 1.6, 1.6.2 , etc
Suppose that now we have Pharo1.1 and you do the same: you copy your new version of the conf to Pharo11MetacelloConfiguration.
How do people know WHICH version of the conf work for EACH pharo version ?�� That's why I had the idea that every developer implement load to instead of loading the last version, to load the last version that WORKS for that Pharo version.

So probably, the conf you copy to Pharo10MetacelloRepository may be
load
������� self version: '1.0.xx'� load

and in Parho11MetacelloRepository� it would be

load
������ seld version: '1.6.xxx'

�this is just an example.

Having this, it also gives us an API: Everybody will know how to install it: just evaluate load.
And "us" can be extended to a bot -> continuous integration.

What is the alternative?

Stef


> Hi folks. We have been discussing a lot what to do with the Metacello configurations of all projects and MetacelloRepository.
> We want several things:
>
> - Have an specific catalog of the working and tested packages/projects for each Pharo release (1.0, 1.1, etc).
> - Be able to have a hudson server running and testing such configurations.
> - Unified way to load a project.
>
> For such objectives, we propose the following scheme:
>
> 1) We create a squeaksource repository called Pharo10MetacelloRepository
> 2) All the Metacello configurations that are known and tested to work perfect in Pharo1.0, are copied to such repository. (this takes 2 minutes)
> 3) Now, we have the problem of WHICH version from the conf class should be the one that loads and works in Pharo 1.0. So, once you copied the configuration, then you have to implement a class side method "load" that loads the exact version that should work in Pharo1.0. This version may not be the last. And you already may have defined "load" to load the last version. In such case, you can just change it for the version in the Pharo10MetacelloRepository. Otherwise, we can use another message. Give us your opinion.
>
> So the idea is that all developers/maintainers of Metacello configurations, do that and publish it. With this, if you want to know which projects work on Pharo 1.0 you just browser Pharo10MetacelloRepository, load the repository you want, and you know that just doing "ConfigurationOfXXX" load will do the job.
>
> In addition to this, we are able to have a hudson server that every XX time, it scans the repository, and for each project it tries to load it and report if there is a problem. We can even make that "load" loads also the tests and make Hudson to run the tests. Or if you want we can use another message than load.
>
> So...this is just an idea. But we need feedback and hear opinions. Because Pharo 1.1 will be soon and would be great to have this already working for Pharo 1.0.
>
> Thanks
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project