We got a discussion with dale/simon/mariano and I'm sure that dale will reply. Stef On Sep 15, 2010, at 4:36 PM, Miguel Enrique Cobá Martínez wrote:

El mié, 15-09-2010 a las 15:52 +0200, Torsten Bergmann escribió:

...

One thing I think that should be discussed at ESUG (sorry I'm not there) is if and how we want to maintain Metacello repositories for the different Pharo versions in the future.

I still think about the project/repo dependency issue:

An example: we have a repo for Pharo 1.2:

MetaRepoForPharo12 it may contain a ConfigurationOfFFI that works for Pharo 1.1. and loads FFI. it may also contain a ConfigurationOfExternalBrowser that requires the ConfigurationOfFFI (usual Metacello project dependency)

When Pharo 1.3 comes out we have a new MetaRepoForPharo13 and may just copy ConfigurationOfFFI over since it only loads packages and these packages may be compatible to Pharo 1.3. So far so good ... but:

What about ConfigurationOfExternalBrowser, if we just copy it to the new repo the config still points to the "old" ConfigurationOfFFI in the old MetaRepoForPharo12 repo and not to the new one in MetaRepoForPharo13.

So we will have to adopt the configs for any new platform version ... and since world keeps spinnning we may also end up with forked configurations.

Yes, that is expected. Mariano proposed some script that programmatically rewrites a configuration fixin and repointing dependencies to the new repository. This could be triggered when creating a new Repo and when automatically copying every configuration from the previous repo to the new repo.

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

Hi Mariano, 2010/9/16 Mariano Martinez Peck <marianopeck@gmail.com>:

Hi. I don't like to loose my time of ESUG answering/reading emails, but a summary was that we can implement something like #latestVersion or #lastVersion but called #stableVersion which could be something like this:

ConfigurationOfXXX >> stableVersion      for: #pharo10 do: [  ^ self version: '1.35.5' ]

     for: #pharo11 do:  [  ^ self version:  '3.23' ]

     for: #pharo12 do: [  self error: 'Not yet supported' ]

Maybe you could implement some form of forGreaterThan: #pharo12 do: [ ... ] ? so developers do not have to monitor new Pharo versions and update their configurations. Does it makes sense? Cordialement,

Then the user can do something like:

ConfigurationOfXXX project stableVersion load.

And Metacello will load the stable version for the current Pharo version you are running in. And he will apply and use probably the same for the different Gemstone versions.

In addition, even if not needed, we could commit this confs (with this new #stableVersion) into the 3 different MetacelloPharo repositories. With this, it is easier to know which confs work for each pharo versions.

Finally, we thought I could do a test of implementing all those #stable methods in all the confs of the PharoDev  and   try to recreate a Pharo1.0 dev and a Pharo 1.1 dev, using the correct core but using this "stable" version and see if it works.

Cheeers

Mariano

-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

On 23.09.2010, at 09:41, Mariano Martinez Peck wrote:

On Thu, Sep 23, 2010 at 4:46 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote: Hi Mariano,

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

...

Hi. I don't like to loose my time of ESUG answering/reading emails, but a summary was that we can implement something like #latestVersion or #lastVersion but called #stableVersion which could be something like this:

ConfigurationOfXXX >> stableVersion for: #pharo10 do: [ ^ self version: '1.35.5' ]

for: #pharo11 do: [ ^ self version: '3.23' ]

for: #pharo12 do: [ self error: 'Not yet supported' ]

Maybe you could implement some form of

forGreaterThan: #pharo12 do: [ ... ] ?

but what would you do inside the block? I guess doing something like "self error: 'Not yet supported'"

We also thought with Dale, what happens if the Pharo version where you are loading it, does not have an entry in that method....suppose I am now in Pharo 1.3, and I send #stableVersion....what happens? Two options:

- Load the latest one, and nobody knows if that will work or not (I don't like this option) - Thrown an error like "There isn't any stable version specified for this Pharo version" or something like that

what do you think?

I think the basic idea is "I know more or less that it works for this and that between version x and version y". If you combine this with promises you can make regarding the software then you would probably say - the xxx stuff changed from pharo 1.1 to pharo 1.2. I rely on the 1.2 stuff. So I can say at least you need _a_ 1.2 version. That you know for sure - there is no need to assume that the stuff you referring to will change immediately to something different. So together with the above statement that will be >= 1.2 - if you encounter a problem with 1.3 not working with your software than you will even need < 1.3. - everything above is complicated if you replace the real package names with virtual ones. So you can say: Oh, they changed the networking stuff from 1.1 to 1.2 but I want my software to run on 1.1 as well. This is possible if there is a virtual package network-1.2 that can be provided by pharo 1.2 (of course) but also from a compatibility package for 1.1 that provides the same API - you can imagine the compatibility package approach could also work for the 1.3 version but I never encountered a compat package that downgrades an API To me that is the basic assumptions that give you: <, <=, =, >=, > relationship of dependencies (or a combination of those to get a range) Taking the installable targets, stable is strong promise. So you end up reducing the range acquired above to a single version of a package. A beta label is similar. On the other hand bleedingEdge is also a promise :) You will always get the upper bound of the range, the newest package known to probably work. For those you don't know it I strongly recommend reading the debian policy about packages [1]. They went down a long road and you can get the idea what will end up with if you proceeding to cover use cases. hope this helps in any way. My 2 cents, Norbert [1] http://www.debian.org/doc/debian-policy/ch-relationships.html

so developers do not have to monitor new Pharo versions and update their configurations. Does it makes sense?

Cordialement,

...

Then the user can do something like:

ConfigurationOfXXX project stableVersion load.

And Metacello will load the stable version for the current Pharo version you are running in. And he will apply and use probably the same for the different Gemstone versions.

In addition, even if not needed, we could commit this confs (with this new #stableVersion) into the 3 different MetacelloPharo repositories. With this, it is easier to know which confs work for each pharo versions.

Finally, we thought I could do a test of implementing all those #stable methods in all the confs of the PharoDev and try to recreate a Pharo1.0 dev and a Pharo 1.1 dev, using the correct core but using this "stable" version and see if it works.

Cheeers

Mariano

-- Hernán Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

_______________________________________________ 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