Before thinking how to store the configurations for the different versions of pharo(which I see as branches) we should think how to mantain different branches for each project with monticello in a comfortable way...
Maybe the solution is to have one repository for each project, but I don't know if that make us lose history... 2010/8/12 Mariano Martinez Peck <[email protected]> > Hi Miguel. Sorry I was in a mini-holidays. > > thanks for the push :) > > Two weeks before (or similar) before this email, I've already created the > repositories: > > http://www.squeaksource.com/Pharo10Metacello > > and > > http://www.squeaksource.com/Pharo11Metacello > > > I didn't send any email because I was not sure about certain points. I want > to discuss them now: > > 1) Problem: know which project version must be used for a particular pharo > version. There are two solutions: > > a) When a developer commites ConfigurationOf to a particular repo, it makes > sure the #lastVersion answer the correct one. > b) When a developer commites ConfigurationOf to a particular repo, it makes > sure the #load will load the correct version. > > a) is more complicated and require more time for the developer. It means > you will have separate branches for each pharo version. The information is > spread. > with b) all the information is together in only one ConfOf in your own > repo. Once it is needed, you just commit it to a particular Pharo repository > and just change the #load > I think b) is muuuuch easier. > So...everybody knows how to install something "ConfigurationOf load". > > 2) Problem: projects may refer to other projects. And the referenced > projects can be anywhere (for example, metacello repository). Example of > ConfigurationOfOmniBrowser >> baseline11: > > project: 'Refactoring-Core' with: [ > spec > className: 'ConfigurationOfRefactoringBrowser'; > loads: #('Refactoring-Core' ); > file: 'ConfigurationOfRefactoringBrowser'; > repository: ' > http://www.squeaksource.com/MetacelloRepository' ]; > > So....ok., ConfigurationOfOmniBrowser will be in Pharo10Metacello > (example). But...it will load the ConfigurationOfRefactoringBrowser from > MonticelloRepository....WRONG!!! > > solution? > a) change everything by hand....crap > b) use repositoryOverride: > > b) can be used, but the problem (if I understood correclty) is that it > replaces ALL repositories. So, you need to have EVERYTHING in that repo in > order to work. > > > 3) Problem: people will start to submit, may not maintain anymore, etc. I > wouldn't make gloabl write such repositories. We should only give access to > those that need it > > > For me the most complicated problem is b). Ideas? > > Cheers > > Mariano > > > > > On Wed, Aug 4, 2010 at 7:29 PM, Stéphane Ducasse < > [email protected]> wrote: > >> >> >> > >> > I have read the discussions and yes that would be good but some things >> > concern me: >> > - Repository size (maybe this is not a problem but the squeak source >> > downtime come to mind) >> memory disc is cheap >> >> > - Load in the squeak source when sync is being done. >> yes >> >> > - Who syncs the packages, Metacello when uploading¡ Some webmaster? A >> > cron? >> the commiter press a button: "archive" and as a side effect all >> the packages are recursively pulled up and save :) >> >> > - What about conflicting names in packages. >> I would not bother right now. >> >> > - Maybe RFB-MiguelCoba.25 in ConfigurationOfRFB ask it from lukas repo >> > and ConfigurationOfOtherPackage requires RFB-MiguelCoba.25 from >> > squeaksource RFB repository and for any reason the packages are distinct >> > (maybe a bug was found and republished in lukas repo with the same >> > version number, but squeaksource version was copied before the fix was >> > done) >> >> the one loaded by the config should be the one saved. >> >> > Maybe those problems never show. Anyway, the idea of having all >> > available is good, but maybe not a task of Metacello, but as an >> > independent effort. Metacello will just use the redundant repositories >> > when installing a package. >> > >> > >> > Cheers >> > >> >> >> >> Else this is great. >> >> >> >> Stef >> >> >> >> >> >> On Aug 4, 2010, at 11:41 AM, Adrian Lienhard wrote: >> >> >> >>> Hi Miguel, >> >>> >> >>> Thanks! It's great to see progress on this front! >> >>> >> >>> Cheers, >> >>> Adrian >> >>> >> >>> On Aug 4, 2010, at 10:21 , Miguel Enrique Cobá Martínez wrote: >> >>> >> >>>> Hi all, >> >>>> >> >>>> I have created three new repositories on squeaksource: >> >>>> >> >>>> http://www.squeaksource.com/UniverseForPharo10 >> >>>> http://www.squeaksource.com/UniverseForPharo11 >> >>>> http://www.squeaksource.com/UniverseForPharo12 >> >>>> >> >>>> They are the repositories for the current versions of Pharo. The idea >> is >> >>>> that each new release add a new UniverseForXXX repository and >> populates >> >>>> it with the current UniverseForXXX packages of the stable release. >> >>>> >> >>>> Right now they are mostly empty, but should be populated by the >> >>>> community and the ConfigurationOfXXX maintainers. >> >>>> >> >>>> Most ConfigurationOfXXX packages in >> >>>> >> >>>> http://www.squeaksource.com/MetacelloRepository >> >>>> >> >>>> should be copied to UniverseForPharo10. Which versions? The last >> known >> >>>> version that is working correctly on Pharo 1.0. This will be the >> >>>> official universe for Pharo1.0. No ConfigurationOfXXX should be >> stored >> >>>> on UniverseForPharo10 if it is not working correctly on Pharo10. >> >>>> >> >>>> Then two things can follow: >> >>>> >> >>>> - If the package already has ConfigurationOfXXX package versions that >> >>>> work in Pharo 1.1, those versions should be copied to >> >>>> UniverseForPharo11. >> >>>> >> >>>> - If the ConfigurationOfXXX only works for Pharo1.0 and the >> maintainer >> >>>> want to create the configuration for Pharo 1.1, he/she must copy the >> >>>> last working configuration for the package from UniverseForPharo10 to >> >>>> UniverseForPharo11. There he/she can start modifying the package >> until >> >>>> it works correctly in Pharo1.1 (use the blessing: tags wisely to >> avoid >> >>>> marking a broken configuration as released) >> >>>> >> >>>> This will permit to populate the UniverseForPharo11 based on the last >> >>>> working package versions from UniverseForPharo10. From that point >> they >> >>>> will likely diverge because of maintenance releases to the packages >> in >> >>>> any UniverseForXXX repository. >> >>>> >> >>>> The same will must be done to migrate from UniverseForPharo11 to >> >>>> UniverseForPharo12. You get the idea. >> >>>> >> >>>> With time, MetacelloRepository should be deprecated in favor of this >> >>>> UniverseForXXX repositories. >> >>>> >> >>>> Anyone is free to copy a working version from a previous Universe to >> a >> >>>> new Universe. They have read/write permissions to all. >> >>>> >> >>>> This setup will avoid the problems we are having right now with the >> >>>> in-image changes that are rendering the ConfigurationOfXXX unusable >> in >> >>>> distinct releases of Pharo. >> >>>> >> >>>> What this means to the end user: >> >>>> >> >>>> - For released version of Pharo >> >>>> >> >>>> They will have to use gofer this way: >> >>>> >> >>>> Gofer new >> >>>> squeaksource: 'UniverseForPharo10'; "Or UniverseForPharo11" >> >>>> project: 'ConfigurationOfMagma'; >> >>>> load. >> >>>> ConfigurationOfMagma project latestVersion load. >> >>>> >> >>>> - For next releases of Pharo >> >>>> >> >>>> Gofer loadFromUniverse: 'Magma'. "Or with GoferProjectLoader" >> >>>> ConfigurationOfMagma project latestVersion load. >> >>>> >> >>>> All this depends on conventions to find the appropriate universe for >> >>>> each pharo release, and also in the support from tools (like gofer in >> >>>> this example or the GoferProjectLoader if it is part of the core >> image). >> >>>> The universe functionality of the tools right now rely on the >> >>>> SystemVersion current majorMinorVersion string for deciding which >> >>>> repository to connect to. This could be improved surely but for now >> it >> >>>> works. >> >>>> >> >>>> I'm loading a new version of Gofer to PharoInbox with this >> functionality >> >>>> added so if you want to load directly from the universes with gofer >> do: >> >>>> >> >>>> Gofer upgrade. >> >>>> Gofer loadFromUniverse: 'YourPackageAlreadyInAUniverse'. >> >>>> >> >>>> But wait to this change to be treated by Stephane or Lukas before >> >>>> attempt it. >> >>>> >> >>>> Right now there is only Magma in the three repositories, but it >> >>>> shouldn't be hard for the maintainers of the other Configurations to >> >>>> help populate the universes from Pharo1.0, Pharo1.1 and Pharo1.2. >> >>>> >> >>>> This will benefit us as a community because the universes for the >> >>>> released pharo versions will be mostly untouched (only maintenance >> >>>> releases) and people will have the freedom to modify the >> configuration >> >>>> in the unstable (currently UniverseForPharo12) universe without >> >>>> affecting the users of the stable versions. >> >>>> >> >>>> Also, this will avoid to have a lot of conditionals inside the >> >>>> ConfigurationOfXXX classes, because a given class will target a >> specific >> >>>> Pharo release (the version on the newest universes could even delete >> the >> >>>> methods for the old universe, because will likely won't work in the >> new >> >>>> universe, deleting unnecessary and legacy code from the >> configuration) >> >>>> >> >>>> Comments and improvements welcome >> >>>> >> >>>> -- >> >>>> Miguel Cobá >> >>>> http://miguel.leugim.com.mx >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> > >> > -- >> > Miguel Cobá >> > http://miguel.leugim.com.mx >> > >> > >> > _______________________________________________ >> > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
