30 Sep
2015
30 Sep
'15
4:15 p.m.
On 30/09/15 15:10, phil(a)highoctane.be wrote:
Why not put a version of the config in the
Pharo40Metarepo and leave
it at that?
As the new stuff occurs in Pharo5, new configs should go in a
Pharo50Metarepo and not affect anything in 4.0
Feeback welcome.
We will have a year of bug fixes in Pharo 4. The core development moves
to Pharo 5, and not all other projects do the same. Lots of projects
want to be a bit behind the bleeding edge, or even only build on
released versions. A Configuration describes how to load things in each
version of Pharo/Gemstone/Squeak (that the project wants to support).
Projects that do not want to be on the bleeding edge still want bug
fixes. That means they always want the latest version of every
configurationOf they use (not necessarily the latest version found in
that configurationOf, though).
If the development of a dependency happens in Pharo 5 and only bugfixes
are backported to Pharo 4, it is fine to depend on the latest released
version on Pharo 4 (that can be #'stable') as long as the bugfixes don't
affect the api you use. This only works if that also goes for the
dependencies of the dependency etc...
If the development of a dependency happens in Pharo 4 or both 4 and 5,
the dependency needs to release a symbolic version that marks the
version at the time of the Pharo 4 release. That can be updated with
non-breaking fixes.
What we now see is GlamourCore depending on an old version of Rubric,
and Roassal2 depending on GlamourCore. Three different projects are now
hard connected to each other with the numbered versions. Breaking that
hard dependency would help. That might need adding symbolic versions to
Rubric.
Another issue is the old configurations in the Pharo 4 build. I'm not
sure why they are not updated.
Stephan
Stephan