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