Metacello repositories in the future
Locked
Metacello repositories in the future
 
|
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. Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Metacello repositories in the future
|
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Metacello repositories in the future
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Metacello repositories in the future
|
|
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 <[hidden email]> wrote: We got a discussion with dale/simon/mariano and I'm sure that dale will reply. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Metacello repositories in the future
|
|
In reply to this post by Torsten Bergmann
Torsten,
I assume that you've seen the mail from Mariano where he describes the proposed approach ... in the next week or so I will implement the proposal so that folks can validate the proposal before unleashing it ... The key component to the proposal is that the configurations are _not_ forked ... the same config version can be used for all versions of Pharo and in all repositories. Dale Torsten Bergmann wrote: > 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. > > Bye > T. > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
Hi Mariano,
2010/9/16 Mariano Martinez Peck <[hidden email]>: > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Metacello repositories in the future
|
|
On Thu, Sep 23, 2010 at 4:46 AM, Hernán Morales Durand <[hidden email]> wrote: Hi Mariano, 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? mariano so developers do not have to monitor new Pharo versions and update _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Metacello repositories in the future
|
|
On 23.09.2010, at 09:41, Mariano Martinez Peck wrote: 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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |