Javier,
I agree with Stef, that duplication isn't an issue - the duplicated bits
are static.
An individual developer has many routes for building/configuring an
application that runs on multiple versions/platforms, but the idea of
"metacello universes" is aimed at helping _users_ figure out what
configurations are "known to work in a particular version."
The repository per release idea has very few moving parts, can be done
now, and addresses the main problem, so it should be done.
On the other hand, we shouldn't stop looking for better ways to "skin
the cat":)
Dale
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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
