Doru wrote:
That would not work well now because of a conflict with merging in Pharo 4 which requires concrete version numbers for now.
Ahh, didn't know that. I assume that is something that will be resolved soonish?
So, I suggest we leave GToolkit related configurations to be as they are and we will depend on the #stable of GToolkit. This should be fine given that we do not expect much changes in Pharo 3, and we will have to change the way we approach to overall process from Pharo 4 on.
Would that be Ok?
Let me think and check out loud.
There is lots of development in GToolkit, so it will definitely break very fast after release, and the developers also have time and access to patch configurations, so they can fix problems quickly. Not nice, but no deal breaker.
ConfigurationOfGToolkit already has different baselines for Pharo 3 and 4
development: spec <symbolicVersion: #'development'>
spec for: #'common' version: '0.6-baseline'. spec for: #'pharo3.x' version: '0.18-baseline'. spec for: #'pharo4.x' version: '0.17-baseline'
so an alternative could be to also have different versions of the other GT configurations. The Pharo3 one using symbolic names, the 4 version not.
The GToolkit related configurations include Rubric, DeepTraverser and NewDebugger so the change scope is limited.
I assume ConfigurationOfGlamour can use symbolic dependencies to roassal2 and glamour core?
I'd prefer adding a symbolic version, but can live with the numbered version in GToolkit related configurations
Stephan
Hi,
We just need numbered versions for the configurations that are linked to pharo:
ConfigurationOfGlamourCore ConfigurationOfGTInspectorCore ConfigurationOfGTPlaygroundCore ConfigurationOfRubric
I permanently update these configurations every time we integrate into pharo. For the rest there is no problem to use #stable
Cheers, Andrei
On Wed, Dec 10, 2014 at 8:40 AM, Stephan Eggermont stephan@stack.nl wrote:
Doru wrote:
That would not work well now because of a conflict with merging in Pharo 4 which requires concrete version numbers for now.
Ahh, didn't know that. I assume that is something that will be resolved soonish?
So, I suggest we leave GToolkit related configurations to be as they are and we will depend on the #stable of GToolkit. This should be fine given that we do not expect much changes in Pharo 3, and we will have to change the way we approach to overall process from Pharo 4 on.
Would that be Ok?
Let me think and check out loud.
There is lots of development in GToolkit, so it will definitely break very fast after release, and the developers also have time and access to patch configurations, so they can fix problems quickly. Not nice, but no deal breaker.
ConfigurationOfGToolkit already has different baselines for Pharo 3 and 4
development: spec <symbolicVersion: #'development'>
spec for: #'common' version: '0.6-baseline'. spec for: #'pharo3.x' version: '0.18-baseline'. spec for: #'pharo4.x' version: '0.17-baseline'
so an alternative could be to also have different versions of the other GT configurations. The Pharo3 one using symbolic names, the 4 version not.
The GToolkit related configurations include Rubric, DeepTraverser and NewDebugger so the change scope is limited.
I assume ConfigurationOfGlamour can use symbolic dependencies to roassal2 and glamour core?
I'd prefer adding a symbolic version, but can live with the numbered version in GToolkit related configurations
Stephan
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev