Hi Stef, You obviously didn't read Andreas post. Please do it, it is really good idea, which includes Metacello, it is simple and very similar to Mariano's proposal. This means that a common solution for both Squeak and Pharo is around a corner and that's what we all want! Best regards Janko On 16. 05. 2010 18:26, Stéphane Ducasse wrote:

...

I think Andreas' recent post to squeak-dev is most cogent o this topic:

Eliot believe me we talk a lot of metacello since at least ESUG last year :) We support and appreciate dale's effort (even when people bashed metacello a while ago). So I think that we have a solution that looks ok for us. We started to see how we can manage pharoCore to produce pharoMini using metacello and what hamper us to remove more aggressively package is the speed of load monticello packages.

Stef

-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

another cool thing is that we are going to be able to distribute a Pharo release with the correct repository as default (already added in Monticello Browser) So, in Pharo1.0 we add by default the repo Pharo10MetacelloRepository for Pharo1.1 we add Pharo11MetacelloRepository. Then, when someone wants to install something, just need to browse the repository, select what he wants, load it and then just evaluage ConfigurationOfXXX load. Cheers mariano On Sun, May 16, 2010 at 9:17 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

Yes, it is similar to Andreas post. We were thinking about this since a lot of time but without making progress. Now, with the post of Andreas, we remembered about it. And I am happy both proposal are similar. Little differences:

- They want one only package for all confs. We want one package per configuration. Like we did in MetacelloRepository. I think it is easier to manage, less conflicts (imagine if everybody is commiting in the same package) and easier to browse.

- They didn't say how to solve the problems with multiple version. What will they do when they have squeak 5 ? use the same package ? another one ? other repo ?

- How do they know which version of the configuration works on the current version of squeak? So...I browse ConfigurationOfFFI, how do I know that the version 1.1.4 is the one that works in Squeak 4.1 and that the 1.2 is the one that works in Squeak 4.2 ? Of course, you can put such information inside the configuration, maybe in #description: or similar...but in all cases, you have to enter and browse the conf. We don't want that.

- We wanted to define a standard way to load the packages on such repository: just send the message load.

I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed.

What we want in summary is: is a repository of projects tested that works for a particular release of Pharo and that they all get installed in the same way. And that such installation can be executed any time in future.

Cheers

Mariano

2010/5/16 Janko Mivšek <janko.mivsek@eranova.si>

Hi Stef,

...

You obviously didn't read Andreas post. Please do it, it is really good idea, which includes Metacello, it is simple and very similar to Mariano's proposal. This means that a common solution for both Squeak and Pharo is around a corner and that's what we all want!

Best regards Janko

On 16. 05. 2010 18:26, Stéphane Ducasse wrote:

...

...

I think Andreas' recent post to squeak-dev is most cogent o this topic:

Eliot believe me we talk a lot of metacello since at least ESUG last year :) We support and appreciate dale's effort (even when people bashed metacello a while ago). So I think that we have a solution that looks ok for us. We started to see how we can manage pharoCore to produce pharoMini using metacello and what hamper us to remove more aggressively package is the speed of load monticello packages.

Stef

-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

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

+ 1 especially on this one.

I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed.

Yes, it is similar to Andreas post. We were thinking about this since a lot of time but without making progress. Now, with the post of Andreas, we remembered about it. And I am happy both proposal are similar. Little differences:

- They want one only package for all confs. We want one package per configuration. Like we did in MetacelloRepository. I think it is easier to manage, less conflicts (imagine if everybody is commiting in the same package) and easier to browse.

- They didn't say how to solve the problems with multiple version. What will they do when they have squeak 5 ? use the same package ? another one ? other repo ?

- How do they know which version of the configuration works on the current version of squeak? So...I browse ConfigurationOfFFI, how do I know that the version 1.1.4 is the one that works in Squeak 4.1 and that the 1.2 is the one that works in Squeak 4.2 ? Of course, you can put such information inside the configuration, maybe in #description: or similar...but in all cases, you have to enter and browse the conf. We don't want that.

- We wanted to define a standard way to load the packages on such repository: just send the message load.

I still would like to hear the opinion of the developers that have most of the configurations. We are doing this together. If you don't agree, it will not succeed.

What we want in summary is: is a repository of projects tested that works for a particular release of Pharo and that they all get installed in the same way. And that such installation can be executed any time in future.

Cheers

Mariano

2010/5/16 Janko Mivšek <janko.mivsek@eranova.si> Hi Stef,

You obviously didn't read Andreas post. Please do it, it is really good idea, which includes Metacello, it is simple and very similar to Mariano's proposal. This means that a common solution for both Squeak and Pharo is around a corner and that's what we all want!

Best regards Janko

On 16. 05. 2010 18:26, Stéphane Ducasse wrote:

...

...

I think Andreas' recent post to squeak-dev is most cogent o this topic:

Eliot believe me we talk a lot of metacello since at least ESUG last year :) We support and appreciate dale's effort (even when people bashed metacello a while ago). So I think that we have a solution that looks ok for us. We started to see how we can manage pharoCore to produce pharoMini using metacello and what hamper us to remove more aggressively package is the speed of load monticello packages.

Stef

-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

_______________________________________________ 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

well... I read it before and the answer I sent to the remark of eliot is still valid. Did you realize that we think about package since we started to work on 3.9, so having a system like metacello was really what we wanted because packages without management of dependency cannot scale. Stef On May 16, 2010, at 8:47 PM, Janko Mivšek wrote:

Hi Stef,

You obviously didn't read Andreas post. Please do it, it is really good idea, which includes Metacello, it is simple and very similar to Mariano's proposal. This means that a common solution for both Squeak and Pharo is around a corner and that's what we all want!

Best regards Janko

On 16. 05. 2010 18:26, Stéphane Ducasse wrote:

...

...

I think Andreas' recent post to squeak-dev is most cogent o this topic:

Eliot believe me we talk a lot of metacello since at least ESUG last year :) We support and appreciate dale's effort (even when people bashed metacello a while ago). So I think that we have a solution that looks ok for us. We started to see how we can manage pharoCore to produce pharoMini using metacello and what hamper us to remove more aggressively package is the speed of load monticello packages.

Stef

-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

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

2010/5/16 Mariano Martinez Peck <marianopeck@gmail.com>

2010/5/16 Eliot Miranda <eliot.miranda@gmail.com>

...

I think Andreas' recent post to squeak-dev<http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html>is most cogent o this topic:

why ?

Read it and you'll see. But the most important thing is that there is one place to find all the external packages which are "supported", or part of the base distribution but not bundled. It is in the image so it can be updated to keep it current. I think its better than the external repository (doesn't force a single repository). But read Andreas' message. He motivates the idea very well; cogently no less :)

...

...

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

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

Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again... As for the Preferences/Settings, Pharo choices are probably very weel thought. However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context... I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL. You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale. The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again, Nicolas 2010/5/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Elliot believe me we **really** discussed that over more than a year with dale and a couple of others. We pushed metacello contrary to other people that said it was crap and bloated. So may be we are a bit slow and not that smart but we want to give a try to the setup we have in mind. Now we also want to have a list of packages which constitutes pharo-core that will be manage as a pharo-core configuration.

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

The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process. Best regards Nicolas 2010/5/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:

nicolas

all the information is in the metacello mailing-list  and we already posted many mails on that topics in this mailing list. I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood in a nutshell

one repo per version Pharo1.0, Pharo11 ... MetacelloRepository        containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load.

a project        contain its single/or whatever configurationOfMyProject        people publish the config to their repository and if they want they push from their repository to the version repository        a version that they freeze (may be using tags)

For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages.

Then we have a server that load configuration and barks if something wrong happen. And may be we kick out the configurationofXXX from MetacelloRepositories

...

Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again...

more than that. :) It looks like if we did not talk or think about what we are doing.

...

As for the Preferences/Settings, Pharo choices are probably very weel thought.

However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context...

I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL.

You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale.

The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again,

So to fix the problem consider that as our proposal.

Stef

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

Hi, I like this approach: 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. Cheers, Doru On 18 May 2010, at 09:32, Stéphane Ducasse wrote:

I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple

========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load.

A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load.

For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages.

We can use automatic build server to validate the status or migration between different repositories ==========================================================

Stef

On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote:

...

The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process.

Best regards

Nicolas

2010/5/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

nicolas

all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood in a nutshell

one repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load.

a project contain its single/or whatever configurationOfMyProject people publish the config to their repository and if they want they push from their repository to the version repository a version that they freeze (may be using tags)

For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages.

Then we have a server that load configuration and barks if something wrong happen. And may be we kick out the configurationofXXX from MetacelloRepositories

...

Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again...

more than that. :) It looks like if we did not talk or think about what we are doing.

...

As for the Preferences/Settings, Pharo choices are probably very weel thought.

However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context...

I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL.

You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale.

The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again,

So to fix the problem consider that as our proposal.

Stef

_______________________________________________ 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

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

-- www.tudorgirba.com "Every thing has its own flow."

Yes, I don't think that it is a good idea to modify the configuration when it is published in the PharoXXMetacelloRepository. In the end the reason for this discussion revolves around the desire to provide a simple method for developers/users to load projects that are "known/tested to work in PharoXX". Creating a PharoXXMetacelloRepository means that we have a "white list" of configurations that are"known/tested to work in PharoXX". GoferProjectLoader provides an API for loading projects from a target repository. The API makes it very simple to load a particular project by name, without having to specify more details about the version of groups involved. It also means that one can arrange to do special things under the cover of the GoferProjectLoader, like point to a different repository based upon the version of Pharo that it is running in ... I think that what we need in addition to a "white list" of projects, a "white list" of _versions_ that are "known/tested to work in PharoXX." I think it would be straightforward to subclass/extend the GoferProjectLoader to add the notion of a version/group "white list" that records the exact configuration/version/group(s) that have been tested and known to work. This same extension to GoferProjectLoader can automatically include an overrideRepositories: to ensure that all projects/packages are loaded from the PharoXXMetacelloRepository repository... By default, the GoferProjectLoader loaded into PharoXX would point to PharoXXMetacelloRepository and use the "white list" of versions. Once a developer/user has become comfortable using PharoXX, he/she can configure GoferProjectLoader to suit his/her needs as well as directly load Configurations/versions that are not on the "white list" (using Metacello directly) without requiring any changes to the configurations or where they originated from... So in the end the following expression will do things differently depending upon a) which version of Pharo it is executed in and b) whether or not you are using the 'default' GoferProjectLoader: Gofer project load: 'SqueakDBX'. All while using the same Configuration... Dale Stéphane Ducasse wrote: Yes I think that this is what dale proposed. Dale is off line today but he will probably comment Stef On May 18, 2010, at 10:59 AM, Tudor Girba wrote: Hi, I like this approach: 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it. The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository. Cheers, Doru On 18 May 2010, at 09:32, Stéphane Ducasse wrote: I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple ========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load. A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. We can use automatic build server to validate the status or migration between different repositories ========================================================== Stef On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process. Best regards Nicolas 2010/5/17 Stéphane Ducasse <stephane.ducasse@inria.fr><mailto:stephane.ducasse@inria.fr>: nicolas all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood in a nutshell one repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. a project contain its single/or whatever configurationOfMyProject people publish the config to their repository and if they want they push from their repository to the version repository a version that they freeze (may be using tags) For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. Then we have a server that load configuration and barks if something wrong happen. And may be we kick out the configurationofXXX from MetacelloRepositories Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again... more than that. :) It looks like if we did not talk or think about what we are doing. As for the Preferences/Settings, Pharo choices are probably very weel thought. However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context... I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL. You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale. The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again, So to fix the problem consider that as our proposal. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto: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<mailto: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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow." _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi, Well, the whole point of the "publish" idea would be to ensure a safe and guarded place from which everything can be loaded. If you depend on other repositories, these can disappear in time and you are back to the same problem as now. So, I think the only way around this problem is to produce configurations that can load only from a controlled repository. Cheers, Doru On 18 May 2010, at 12:03, Mariano Martinez Peck wrote:

On Tue, May 18, 2010 at 10:59 AM, Tudor Girba <tudor.girba@gmail.com> wrote: Hi,

I like this approach: 1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other. 2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it.

The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository.

Thanks Doru for pointing this. Actually, this was the only "problem" I found with the solution. My though about this where:

- I really don't care where they are the confs you depends on. I only care that YOU loads and runs perfectly. - Maybe that other confs that you depend on are also in the same repo...but I don't think something bad to getting the conf from, for example, MetacelloRepository.

You can update the conf once you publish it and to use the PharoXXXMetacelloRepositopry instead of MetacelloRepository or whatever, but I don't think it is strictly needed. What it is needed is that it loads and works ok. If other person, or even you, want to ALSO publish your dependences, great...

What do you think?

Cheers

Mariano

Cheers, Doru

On 18 May 2010, at 09:32, Stéphane Ducasse wrote:

I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple

========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load.

A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load.

For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages.

We can use automatic build server to validate the status or migration between different repositories ==========================================================

Stef

On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote:

The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process.

Best regards

Nicolas

2010/5/17 Stéphane Ducasse <stephane.ducasse@inria.fr>: nicolas

all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood in a nutshell

one repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load.

a project contain its single/or whatever configurationOfMyProject people publish the config to their repository and if they want they push from their repository to the version repository a version that they freeze (may be using tags)

For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages.

Then we have a server that load configuration and barks if something wrong happen. And may be we kick out the configurationofXXX from MetacelloRepositories

Steph, I understand how boring it may seem: - you already discussed the subject over and over - you already took decisions and now we come later with new proposals, and ask you to reconsider the work again...

more than that. :) It looks like if we did not talk or think about what we are doing.

As for the Preferences/Settings, Pharo choices are probably very weel thought.

However, every solution will come with trade offs, and it would be good to have a rationale justifying the choices you made, and perhaps more importantly justifying why you did abandon some solutions, because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... and find different answers in different context. Note that Squeak evolutions might have influence on Pharo too, and it's part of the context...

I strongly encourage you to establish your rationale on Pharo grounds - independently of Andreas proposals, put it on the Pharo wiki and let us know the URL.

You also know that Squeak goals are not exactly those of Pharo w.r.t. backward compatibility, so Squeak can't just blindly replicate Pharo solutions without a rationale.

The merit of Andreas proposal is to try and establish such a rationale. Without it, we're bound to repeat discussions again and again,

So to fix the problem consider that as our proposal.

Stef

_______________________________________________ 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

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

-- www.tudorgirba.com

"Every thing has its own flow."

_______________________________________________ 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

-- www.tudorgirba.com "Be rather willing to give than demanding to get."

El dom, 16-05-2010 a las 09:14 -0700, Eliot Miranda escribió:

Hi Mariano,

I think Andreas' recent post to squeak-dev is most cogent o this topic:

I don't see why. Lets see, Andreas said: "While looking into Metacello I also spent some time at the Pharo Metacello repository on Squeaksource. There are many interesting things to be said about it, both good and bad. Good things about it are that it's community maintained. Everyone can update everyone else's contributions and although that's not generally done, it offers a community approach to making sure things work. Something that for example both Universes and Squeakmap lack completely. What's problematic about the repository on the other hand is that for one thing one needs to unconditionally trust the code even before one has even decided to install it (this by far my biggest complaint about Metacello)." I don't buy this, how is this different than loading a package (Seaside, RFB, whatever) from SqueakSource in my image. Unless I browse the full code in SqueakSource (slow as hell), I don't have any guarantees that the code doesn't does a true become: false in some initialization method somewhere. The same applies to the ConfigurationOfXXX packages. The advantage of loading it to your image is that at least you can use a real environment to analyze the code. If you are using the loader to update your critical mission deployment, well, given the current security foundations of Smalltalk, you're betting to the wrong horse. If you want more security is a matter of signing the package in Squeaksource somehow and checking the signature on loading in the image (like every reasonable linux distro does currently on installing packages), or using some kind of sandbox for loading untrused code. But that is completely other issue and has nothing to do with the Metacello way of work. In fact, Metacello it could be enhanced to check some kind of signature before loading and then the trust problem will be real targeted. "Also, I don't think that a single repository is a feasible option in the long term - it seems to me that supporting the cross-product of image and package versions is going to be problematic before too long. And of course browsing repositories with several dozen of packages to find what you need isn't exactly fun either." Of course, nobody denies that, and in fact is an issue that has been discussed several times before in this list. Check the Loader code that is being worked on. It searches, installs, and is easier to write than directly use ConfigurationOfXXX messages. "However, the problems can be turned on their head, and that's actually pretty insightful. Here's the basic idea: What if, instead of having a single repository for all image versions with separate packages for each config, we would instead have a single package simply called Configurations in the trunk? That Configurations package would contain all the "supported" configurations for Squeak (I'll get to that in a minute). The package would be community-maintained, just like any other package in trunk development process. This addresses the trust issues with Metacello, since the package has the same level of trust that all the other packages in a Squeak release have; it has been developed using the same principles." Won't work, because not everybody works on Squeak, in fact, most ConfigurationOfXXX have been created and tested first on Pharo. The idea Andreas propose is to have a Squeak configuration and Pharo a Pharo configuration, that very likely will be a hell of copy & paste of methods. The good thing of having separate ConfigurationOfXXX packages in a neutral repository (MetacelloRepository) is that everybody can add methods (one for each version and for each one of Squeak and Pharo if necessary) to a only one Configuration. What you propose is to forget that there are users of a package in both camps and that your solution propose that the maintainer create two or more configuration packages in distinct repositories (one for Squeak in trunk repo and one for Pharo in MetacelloRepository). This is not funny. Also, this just add other package to the base image, a package that will change a lot between different Squeak releases. Squeak 5 will have a package with 10 configurations, Squeak 6 will have a package with 45 configurations. The idea of core package or base package is that the package is not changing a lot between releases. Current ConfigurationOfXXX only needs Gofer or Installer in the base image. Maybe a future Pharo release will have Gofer and Loader in the base image but Loader doesn't grow unrestricted between Pharo releases. The MetacelloRepository will do. "What that gives us is a mechanism by which we suddenly can include Omnibrowser, Seaside, Magma, FFI and anything else people can come up with in Squeak without having to preload it in the shipping image." This is funny, I haven't realised that to this day it is imposible to have a Pharo Core image without packages installed by default. Good to know that this will be possible soon with this new Configurations package. "What it also means is that we can start removing packages from the image, replacing them with the proper configurations for how to load them back. What it means is that somebody with a new application (be that Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask for the configuration to be part of the next Squeak release, thereby contributing *directly* to that Squeak version." And this is really what I don't understand of the Squeak fellows, why, why should someone *ask* someone (people or board or institution) for permission to add a package to a released Squeak. Why? Why should I wait for the next release for my package to be *accepted*? This is non-sense. The current state of affairs permit me, even now that Pharo 1.0 has been released, to release my own package *aimed* on Pharo1.0 by just testing that works and publishing my ConfigurationOfXXX in the MetacelloRepository. The proposed solution is just plain wrong and completely "Squeakish" (lets have everything in the image) "Most importantly, however, is that we as the community can decide what we feel we want to support and what not. " What you base your judgements on to conclude this. The community decide what ConfigurationOfXXX is created, tested and maintained or supported. "To do that, I'm proposing to create a status of "Community Supported Package" in Squeak. What is that? A community supported package is a piece of software where we feel this is an important/interesting/novel package that should ship with this Squeak version. A community supported package can be loaded in a 'one-click' process directly from within the image. A community supported package is a package where we provide assurance that the package has been tested for this release." How is this different from the current #released, #stable, #development tags you can use in Metacello to mark the status level of a given package in a given released Pharo or Squeak version? "However, that status does not come for free. In return for achieving this status, the software needs follow the rules for community supported packages, which (at least) should include the following: * No conflicts. Neither class names nor -override categories. The rationale is that all community supported packages can be loaded together without creating conflicts." This is an artificial restriction. Debian and derived ones and Red Hat and derived ones distros permit to install conflicting packages from the same universe without problems. You see, is the decision of the user and not the maintainer or distro packager what to install. For example you can't install (well you can, but you shouln't most times) Sendmail at the same time that Exim or Postfix. They are conflicting packages and the system only warns you about the conflicts. But the system permits you install them if you want. The same applies to the overrides. If I want to install two packages that have overrides over the same methods that is my problem. The system should only warn me and let me do what I want. "* Tests mandatory. A community supported package MUST have tests. The rationale is that since we provide the guarantee that the package has been tested, we need to ensure that testing can be automated to the maximum extent possible. It doesn't mean 100% coverage but *some* meaningful set of tests need to be provided or else we can't say if we broke it in the latest update." This is good no matter the package system on hand. But this is also an artificial restriction. A package can work (and for a lot of people can be useful) even if no single test is provided. Would you denied them the posibility of install the package in your image. There may be some other guidelines that we may want to establish but I'm trying to keep things simple and only the above two are truly crucial - what they allow is to ensure that during ongoing trunk development we will always be able to load all supported packages, run the tests and see if we broke something horribly. So the goal of the process is that if we do this right, we should be able to tell how good (or how bad) a shape we're in regarding the supported packages when we get to ship date. We should be able to encourage people who write libraries or apps with, for, and in Squeak, to contribute directly to the next release by providing a configuration, their code, and the tests so that we can keep things running. In return, we'll help with porting, provide backwards compatibility as required etc. Code that we want to move out of the default image would be moved into a configuration so people can load it if desired, and it remains a part of Squeak instead of rotting away. Since the Configuration package is small and has no dependencies, there's no problem to include that in core/basic images and allow people to tailor custom images from there. Concretely, I'm seeing the following steps as necessary: 1. Establish the status and the rules for "Community Supported Packages". 2. Create the "Configurations" package and start populating it with some examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like. 3. Encourage people to bring their packages up to 'community standards' and include them in the Configurations. From here, there are a few more things that we should do before we can ship the next Squeak version: 4. Provide a better installer than these awful doIts for Metacallo. 5. Establish a test server to automatically verify the community standards for supported packages (i.e., load packages randomly, ensure no conflicts, run tests, report results). At this point, there is another clearly defined way to contribute to Squeak even if you're not a core developer: Develop your software, provide a configuration, ensure your software adheres to the community standards. That's it. You've just made the next Squeak release a little better :-) -- Miguel Cobá http://miguel.leugim.com.mx

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 <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

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

I like the idea of tags. Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD with all the code included. Stef

I was thinking about the "folders" to store copies of ConfigurationOfXXX for a given release. I think that this will have problems, for example for the simplest package that load fine in 3 consecutive release we will have exactly 3 copies of the ConfigurationOfXXX package (not that the disk space is a problem). On the other side, if a package has 19 versions for a given release (lets say RFB has 19 version methods in the ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a copy of it will be made. This copy will be full, having the 19 version methods, or you just take the last version method. Also, what about the pre/post do its, they will likely be similar or exactly equal between releases of Pharo. If you delete the methods, you also lost the history and the opportunity that new users can learn or use the previous versions.

Some time ago I proposed the idea that Metacello should have tags to mark that a version method has been tested in a given fork/release. As the time pass, the tags in a method will grow to mark the version has been tested on. But for this to work, Metacello or the tools (I would prefer Metacello) must honor this tags and before loading the code in a given image by comparing what image is being installed on.

Lets put an example:

1. Initial creation of the configuration for package Package for Pharo 1.0 uploaded to MetacelloRepository:

ConfigurationOfPackage>>baseline01 "initial baseline"

ConfigurationOfPackage>>version01: spec <version: '0.1'>

spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ].

2. A new version for Pharo 1.0 (lets say a bug fix):

ConfigurationOfPackage>>version02: spec <version: '0.2'>

spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ].

3. A new Pharo release is made, no changes to the package are needed, that is, it works correctly in Pharo1.0 and Pharo 1.1

ConfigurationOfPackage>>version03: spec <version: '0.3'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) ... ].

At this point the ConfigurationOfPackage has four methods: baseline and three versions. Also, before loading, Metacello checks the worksIn: list against a standard release string in the image is working on. If it match it install the package. That is, if I start with a Pharo1.1 image and load the configuration, the only possible candidate version to install is the 0.3, because is the only one marked to work in Pharo1.1.

4. A port to Squeak 5 is made. This likely will need a new baseline because will need squeak specific packages to be included (compatibility packages) and also maybe a Pharo compatibility package will be made. Anyway, a new baseline indicating new packages relationships will be made:

ConfigurationOfPackage>>baseline02 "second baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version04: spec <version: '0.4'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ].

At this point the ConfigurationOfXXX is capable of install the last version in Squeak and Pharo.

If I start on Squeak 4.0 then even if I load the ConfigurationOfPackage, no package will be installed because nobody has tested this.

If I start on Squeak 5.0 only version 0.4 can be installed.

If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed

If I start on Pharo 1.3 no package will be installed

5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1

ConfigurationOfPackage>>baseline08 "second baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version09: spec <version: '0.9'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) ... ]. spec for: #pharo do: [ ... ].

6. Installing on Squeak 8 is again supported together with support for Squeak 7.0:

ConfigurationOfPackage>>baseline04 "third baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version10: spec <version: '1.0'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ].

So the tags come and go as the support for given forks and releases are tested. Different versions of the Package package can work in different forks and in different releases of those forks. It is always the job of the interested parties to add support (that is version methods and baselines, or simply tags to the worksIn: list) for a package in a given combination.

What do you think?

Cheers

-- Miguel Cobá http://miguel.leugim.com.mx

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

two points - let us try something simple that we can understand - second the latest only works if nobody publish a broken code in his repository. or you will have to publish the packages tagged 'latest but for stream pharo1.0' So for now let us keep it simple and learn. Stef On May 18, 2010, at 4:17 AM, Miguel Enrique Cobá Martinez wrote:

El lun, 17-05-2010 a las 09:49 +0200, Stéphane Ducasse escribió:

...

I like the idea of tags. Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD with all the code included.

But look at Debian for example. They release a stable release, lets say 5.0 on January 15th. This is a iso image that includes a given set of package versions, lets say

Package A version 1.1 Package B version 2.0 Package C version 2.1

then they continue working on testing and unstable versions of the distro. Of course as the software is used all around the world, the users report bugs and the developers push new versions with the fixes to the debian repositories. The fixes can be bug fixes, security fixes and new features. Only the security fixes and severe bug fixes are pushed to the stable release (as well as to the testing and unstable branches of course). This security fixes are part of the security updates for stable installations of the distro. But.. after a given number of security fixes and severe bug fixes are collected, they release an update for the stable release, even generating new .iso files. Suppose that they release an update in May 1st. They could call it Debian GNU/Linux stable 5.0.1.

The point is, even if I downloaded the stable release on January 15th, it is different from the version you download on May 1st. They are both called debian 5.0 stable and nobody expect that they are bitwise identical.

But, when you install from the version from January and after updating it from the update stream, I get the same packages that the person that install its server from the version of May 1st.

I think the same can happen to Pharo. You release a given set of versions (in the form of configurationOfXXX) but that doesn't means that those are inmutable. They will be updated to match the packages that fix bugs in a given external package.

Now for the generation of the release, you simply script it to use the latest #released version of a configuration. That is the way that Metacello works currently, installing the latest released version by default.

Cheers

...

Stef

...

I was thinking about the "folders" to store copies of ConfigurationOfXXX for a given release. I think that this will have problems, for example for the simplest package that load fine in 3 consecutive release we will have exactly 3 copies of the ConfigurationOfXXX package (not that the disk space is a problem). On the other side, if a package has 19 versions for a given release (lets say RFB has 19 version methods in the ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a copy of it will be made. This copy will be full, having the 19 version methods, or you just take the last version method. Also, what about the pre/post do its, they will likely be similar or exactly equal between releases of Pharo. If you delete the methods, you also lost the history and the opportunity that new users can learn or use the previous versions.

Some time ago I proposed the idea that Metacello should have tags to mark that a version method has been tested in a given fork/release. As the time pass, the tags in a method will grow to mark the version has been tested on. But for this to work, Metacello or the tools (I would prefer Metacello) must honor this tags and before loading the code in a given image by comparing what image is being installed on.

Lets put an example:

1. Initial creation of the configuration for package Package for Pharo 1.0 uploaded to MetacelloRepository:

ConfigurationOfPackage>>baseline01 "initial baseline"

ConfigurationOfPackage>>version01: spec <version: '0.1'>

spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ].

2. A new version for Pharo 1.0 (lets say a bug fix):

ConfigurationOfPackage>>version02: spec <version: '0.2'>

spec for: #common do: [ spec blessing: #release. spec worksIn: 'Pharo1.0' ... ].

3. A new Pharo release is made, no changes to the package are needed, that is, it works correctly in Pharo1.0 and Pharo 1.1

ConfigurationOfPackage>>version03: spec <version: '0.3'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) ... ].

At this point the ConfigurationOfPackage has four methods: baseline and three versions. Also, before loading, Metacello checks the worksIn: list against a standard release string in the image is working on. If it match it install the package. That is, if I start with a Pharo1.1 image and load the configuration, the only possible candidate version to install is the 0.3, because is the only one marked to work in Pharo1.1.

4. A port to Squeak 5 is made. This likely will need a new baseline because will need squeak specific packages to be included (compatibility packages) and also maybe a Pharo compatibility package will be made. Anyway, a new baseline indicating new packages relationships will be made:

ConfigurationOfPackage>>baseline02 "second baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version04: spec <version: '0.4'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ].

At this point the ConfigurationOfXXX is capable of install the last version in Squeak and Pharo.

If I start on Squeak 4.0 then even if I load the ConfigurationOfPackage, no package will be installed because nobody has tested this.

If I start on Squeak 5.0 only version 0.4 can be installed.

If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed

If I start on Pharo 1.3 no package will be installed

5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1

ConfigurationOfPackage>>baseline08 "second baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version09: spec <version: '0.9'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) ... ]. spec for: #pharo do: [ ... ].

6. Installing on Squeak 8 is again supported together with support for Squeak 7.0:

ConfigurationOfPackage>>baseline04 "third baseline, it accounts for install in Pharo and Squeak"

ConfigurationOfPackage>>version10: spec <version: '1.0'>

spec for: #common do: [ spec blessing: #release. spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) ... ]. spec for: #squeak do: [ ... ]. spec for: #pharo do: [ ... ].

So the tags come and go as the support for given forks and releases are tested. Different versions of the Package package can work in different forks and in different releases of those forks. It is always the job of the interested parties to add support (that is version methods and baselines, or simply tags to the worksIn: list) for a package in a given combination.

What do you think?

Cheers

-- Miguel Cobá http://miguel.leugim.com.mx

_______________________________________________ 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

-- Miguel Cobá http://miguel.leugim.com.mx

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

Because I want to have them close to the Pharo repositories :) "Everything was carefully thought" (tm) :) On May 17, 2010, at 3:17 PM, Geert Claes wrote:

Mariano Martinez Peck wrote:

...

1) We create a squeaksource repository called Pharo10MetacelloRepository

Just a wee idea here, since there are all these ConfigurationOfXXX packages, why not have a MetacelloRepositoryForXXX (rather than XXXMetacelloRepository). Maybe ConfigurationRepositoryForXXX is a better name? -- View this message in context: http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-please... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

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

On Mon, May 17, 2010 at 3:50 PM, Geert Claes <geert.wl.claes@gmail.com>wrote:

Stéphane Ducasse wrote:

...

Because I want to have them close to the Pharo repositories :) "Everything was carefully thought" (tm)

Fair enough ... how about PharoConfigurationRepository :)

I have read all replies here and I am still a bit confused, so is it the idea to have a separate repository per release e.g. Pharo10Configurations, Pharo11Configurations etc?

yes

-- View this message in context: http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-please... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

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