El mié, 04-08-2010 a las 23:32 -0300, Javier Pimás escribió: > 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.
Clarity. As is very likely that different releases of a package will have distinct requirements in: - dependencies - preinstall/postinstall actions - registering with system services (menu, mail systems, sockets, startup/stop list) - number of monticello packages composing the package you're installing - use of system infraestructure (announcements, transcript, menus, help system) it will be a nightmare to have code to cope with all those conditions in a single monolithic giant metacello package, even if metacello is capable of do it. What if after 4 years of development the package has had 15 releases, that will means that you'll have possibly 15 baselines/predoits/postdoits all listing in the method pane of the browser. To someone trying to understand the configuration, it will be a lot of junk to discard before he understand only the bits that matter for the release he is interested in. So, it is healthy to have a distinct configuration in each release (even if in the current release started as a copy of the previous release configuration), to crop the things the _maintainer_ thinks are not needed anymore or simply that he doesn't want to maintain anymore. All the software has a lifetime and distinct repositories gives us the possibility to determine the time to end support for a given release Cheers > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <[email protected]> > 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 > <[email protected]>: > 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 > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Cheers > > -- > 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 > > > > -- > Javier Pimás > Ciudad de Buenos Aires > _______________________________________________ > 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
