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' ]
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
On Thu, Sep 16, 2010 at 11:38 AM, Stéphane Ducasse <
[email protected]> wrote:
> 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
> > [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
