First, if you are creating configuration for a project and you have
different code that needs to be loaded depending upon the version of
Pharo into which it is loaded, then you can add attiributes like
#'Pharo1.1' or #'Pharo1.0' to control which packages get loaded into the
image. This is a case where the maintainer _is_ involved in updating the
application to ensure that it runs on both Pharo1.0 and Pharo1.1 or
Pharo1.x.
Secondly, not all maintainer can ensure that their project runs on
Pharo1.0 and Pharo1.1, etc.. So there is a separate problem of
identifying the versions of a project that are _known_ to work in
Pharo1.0 or Pharo1.1.
When a new Pharo1.x arrives, many projects may not work, but over time,
more and more of the projects get ported to Pharo1.x so determining a
means to communicate to users which projects are known to work is important.
I would say that we haven't completely settled the second issue. As
Miguel mentioned, I think it is clear that the following will be part of
the process
- Copy repositories of configurations (+mcz files) for each new
release
- Use version attributes for conditionally loading packages in version
methods.
I think that we're still up in the air (I know that I am) as to the best
method for controlling the actual load. Ideally, the solution would not
involve editing configurations (tags).
Technically, once you copied the configs/mcz files that are known to
work to a Pharo1.0 repository, all you need to do is use
#repositoryOverrides: to force the load to be done from the Pharo1.0
repository, but we want something that is very simple and doesn't
require an extra step and we're still discussing this.
Dale
Andreas Wacknitz wrote:
Am 20.07.10 16:42, schrieb Miguel Enrique Cobá Martínez:
El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribió:
Hi Miguel. I understand your problem, and we are working on that with
Dale and Stef. Having repositories for a specific Pharo version and so
on. But we are just starting....
By the moment, you can use what Sean told you, or, just update the
configuration, but in a new version. I mean....if you had the version
2.3.4 that was released and working in pharo 1.0, then don't touch it,
create a new one, say, 2.4 and that works in 1.1. Of course this is
not the perfect solution, but for the moment. But one thing for sure:
do not update the SAME version that was working for 1.0.
Magma should continue working in 1.0 using the same metacello version.
Exactly. I will do it this night.
BTW. What will be the solution, copying directories (debian does this
too. They copy the repository contents and then diverge from them. The
previous repository only receives bug fixes) but the solution of Dale,
as I understand it uses tags to identify what version is running on and
then load only the packages for that version. This solution is a third
alternative. So by now we have:
- Copy repositories of configurations for each new release
- Use version attributes for conditionally loading packages in version
methods.
- Use tags to mark the pharo release a given version method applies.
Then metacello searches for the version method with the highest number
that is tagged with the release number of the image (got from
SystemVersion)
Cheers
Hi,
Wouldn't it be good to also ask the maintainer of the offending packages
to change the assignments such that Pharo will be happy without changing
the preference?
Regards,
Andreas
_______________________________________________
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
