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