2010/8/12 Guillermo Polito <[email protected]> > 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... > > I think this is confortable: you, developer, ALWAYS work with only ONE ConfiguratioOf that could be committed in the same repo where your code is. In that Conf you have all the hsitpry. Everything. Every X time, you think "mmmmm I will release 4.21 for Pharo 1.0". Perfect. You then commit such version of the Configuration into the repository Pharo10Metacello making that #load loads the 4.21 version. And that's all. You never merge between those packages. You only maintain one, that is commited in your own repo. Then, you just copy them (and change #load) to specific Pharo verisons.
Here there is no need to merge and no problem. I am wrong ? 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
