Hi Mariano,

2010/9/16 Mariano Martinez Peck <[email protected]>:
> 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.

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to