On 30/09/15 15:10, phil@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