Am 21.03.2014 um 15:57 schrieb Johan Brichau <johan@inceptive.be>:
It can be something to try indeed.
Though I believe we all need to move on to using the Metacello scripting API too. That allows the end-user to control what happens with version upgrades, conflicts etc.. Though there are issues with it too, I have been using it for over a year already to prevent pulling in inadvertent version upgrades.
And, btw, all this would not solve the current problem...
Right. Only atomic loading can solve this. Norbert
Johan
On 21 Mar 2014, at 15:24, Diego Lont <diego.lont@delware.nl> wrote:
Hi all,
Recently we had a lot of trouble, because Seaside upgraded its stable version from 2.8 to 3.0. This caused a lot of configurations not to load properly anymore, because #stable was referenced in a lot of release version.
In reaction to that, I advocated to replace references to #stable to specific versions. Downstream configurations should not break if a configuration it depends on upgrades its stable version. Not all projects have adopted this policy, so that is the source of the configuration mismatch.
We also have a different problem, that we used to solve by using #stable. Minor releases, included bug fixes, should be automatically be pulled over in the configurations downstream. So my solution was probably too much cutting corners.
To solve this, I think we should introduce a new symbolic version for projects that are used a lot. For seaside this would mean defining the following versions: #stable28 #stable30 #stable31 These versions should be used when referencing to seaside, as #stable was clear too coarse grained. You do not want a major version upgrade in a dependent configuration, as this can lead to a lot of trouble, but you do want minor changes (patches) pulled in automatically.
If people agree this is a good idea, I will add these versions to Seaside and add the versions #stable10 and #stable11 to grease, and update the downstream configurations that I am allowed to changed. I should have time for this somewhere next week. I will also add the versions #stable30 and #stable31 to Magritte3
Regards, Diego
On 21 Mar 2014, at 14:32, Esteban Lorenzano <estebanlm@gmail.com> wrote:
adding:
ConfigurationOfGrease>>#stable: spec <symbolicVersion: #'stable'>
spec for: #'common' version: '1.1.6'. spec for: #'pharo2.x' version: '1.1.5'
makes voyage *and* seaside load fine in pharo2.0.
I do not think this is a good idea. The problem is that 2 different references to grease exist. These should all correspond to the same version.