Yes.
It makes sense may be could even have
ConfigurationOfXXX freeze
which could do that automatically
Stef
On May 16, 2010, at 6:35 PM, Mariano Martinez Peck wrote:
>
>
> On Sun, May 16, 2010 at 6:24 PM, Stéphane Ducasse <[email protected]>
> 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
> > [email protected]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
