self contained. In a project I do not care what the world is doing. What I want is my exact project to load the way I want and all the time in a productable manner. So I want to control which part may change (my code) and which part is curved into the stone. So duplication is not a problem. Then if I load a specific version then the recursion of the model make sure that it will load all the necessary package. so this is not like we do not have abstractions to build upon.
Stef On Aug 5, 2010, at 4:32 AM, Javier Pimás wrote: > Maybe I saying nonsense, if that is the case just ignore me but... why have > many packages that do almost exactly the same? Aren't you going to get a lot > of repeated code lying around in different packages? ie. I think most > packages have almost exactly the same baselines for pharo1.x. Maybe it's > possible to call the methods baselineXXForPharoXX and let them stay in the > same class and package? Or maybe adding other pragma to specify which pharo > version each baseline/version describes. I'm sure there could be other > solutions. That way you'd have all the configurations in the same place and > also reuse code if needed instead of duplicating it. > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenr...@vmware.com> wrote: > Miguel, > > I think that this kind of approach makes lots of sense ... I've toyed with > the idea of a "white list" of configuration versions, but someone would have > to be responsible for maintaining the "white list" and the users would have > to responsible for using the "white list" ... > > A repository per version is very simple and gives the maintainer flexibility > in managing releases. > > Dale > > > Miguel Enrique Cobá Martínez wrote: > El mié, 04-08-2010 a las 19:52 +0400, Andrey Larionov escribió: > Why there should be repository per release? As i know > MetacelloConfiguration already contains information about compatible > Pharo versions. > > Because is cleaner and as the releases of Pharo diverge a lot more, the > code to install package becomes full of conditionals to handle the > distinct issues with each pharo release. > For example, Magma. Magma 1.1r1 worked good in any pharo 1.0, 1.1 and > 1.2. > But Magma 1.1r2 doesn't work anymore on Pharo1.0 because Pharo 1.0 > doesn't have the classes DirectoryEntryDirectory and DirectoryEntryFile > that are used by the new magma version. > So I had to modify the configuration with conditionals an several > variations of preDoits and postDoits and test what version image is > ConfigurationOfMagma is being ran. After a couple of hours I gave up. > > The correct solution is to have a specific ConfigurationOfMagma for each > released pharo version. > This have benefits also: > - It permits the unstable repository to heavily update the > ConfigurationOfXXX without disturbing or broke the stable ones. > - It permits the ConfigurationOfXXX code to remain clean, without a > conditionals for every posible combination of release image version and > package to be installed version > - It permits the maintainer of a ConfigurationOfXXX to decide when to > stop supporting old version of a certain package by deleting the old > versionXX: methods of the ConfigurationOfXXX in the newer pharo > releases. Not always is good to be able to install each and every > version of a package in the newest release of pharo (maybe even old > versions won't work in the new releases, like the menu registration > issue or classes that doesn't belong to the core image) > - It permits to issue maintenance ConfigurationOfXXX releases for a > stable or "old-stable" image releases, without altering the > configurationOfXXX in other repositories > Cheers > > 2010/8/4 Miguel Enrique Cobá Martínez <miguel.c...@gmail.com>: > El mié, 04-08-2010 a las 11:46 +0200, Torsten Bergmann escribió: > Hi Miguel, > > hey, nice! If we follow this convention then it is easy to implement > a universe browser that selects the correct universe repo and > displays all loadable versions. Loading stuff should just be > a few clicks away - I personally hate all this MC/Gofer typing ... > > Attached is a quick/simple implementation of such a browser: > > Mann, Sie sind über schnell! > > I tested it in PharoCore 1.0 and worked after a few changes, but the > interface is cool. +1 to aim it be the default universe browser in 1.2. > Simple, to the point. > In Pharo 1.0 I had: > > - Open it with Universe open (doesn't register on menu because of the > lacking pragmas) > - UniverseBrowser pharoUniverse returns PharoCore1.0 instead of Pharo10 > to build the universe name. This could be changed in two ways: > - Add a system property that states the image repository: > SystemVersion current universeName "Returns Pharo10 for image > releases 1.0, 1.0.1, 1.0.5, etc) > - Use the equivalent method in the gofer package I uploaded to > PharoInbox (if it is approved, so there is only a unique source for > converting image version string to universe names) > > Other than that, I like the browser. > > > > - file in the attached changeset (I tried in Pharo 1.2) > - open via World menu -> "Universe Browser" > - select the configuration you want and from the context menu choose > -- "Load configuration" -> only the config is loaded > -- "Load configuration and latest version" -> the config and lates version > is loaded > > Have fun! I used Pharo 1.2 - should work in Pharo 1.0 and 1.1 too > (havent tested). > > Bye > T. > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Cheers > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Javier Pimás > Ciudad de Buenos Aires > _______________________________________________ > 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
