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