On 23.09.2010, at 09:41, Mariano Martinez Peck wrote: > > > On Thu, Sep 23, 2010 at 4:46 AM, Hernán Morales Durand > <[email protected]> wrote: > 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: [ ... ] ? > > > 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 > [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
