We will discuss that on a black board at ESUG.
A release is a release and when you release code you do not want to rely
on something that somewhere could change.
Christophe told me that they are doing that in Java world and this is
working.
Now for development you load your baseline and you load symbolic version
of foreign code.
Stef
I agree. This is why I also think that released should point to version
and not symbolic version.
I strongly disagree. A configuration should only change when
there is a meaningful change. Changes in dependencies that do not
change relevant behavior should not propagate.
We achieve that by using #'releasex.x' style versioning. Changes that
are not supposed to change observable behavior and bug fixes get
new numbered versions within the release.
#development versions are updated in place
This is the purpose of symbolic versions to avoid propagation.
In Moose we did not encounter a situation where a month-old numbered
version configuration was still loadable in the latest Pharo.
???
There is a use case for snapshots of exact versions. They don't belong
in configurations.
I do not get what you mean.
Now if I want to deliver exactly the same version I do not see how we
can avoid versions.
And this "nothing observable changes" is a nice idea but what I see is
that often pharo breaks
because of a nothing observable change.
Focussing improvements in Versioner on releasing more often numbered
versions is counter productive. It just generates more work to keep
configurations working.
I do not think so
- in dev you use baseline for you and development for foreign code
- when releasing you freeze.
With nice tool support I do not see why this would not work.
I have been fixing lots of configurations on ci, and nearly all problems
have to do with not using #'releasex.x' style symbolic versioning.
I did not get it so you should explain it better :)
There are two problems:
- Configurations using numbered versions. They break as soon as a
dependent project changes functionality or does a bug fix, often as
a result of underlying code in Pharo changing.
- Configurations using #stable, where the dependent project does
a new release.
Most of the projects on Jenkins are not there to work against release
but day to day changes
in this case they should load latest.
Now Seaside, Grease and Magritte have switched to this style of
versioning, the number of problems has reduced drastically.
Stephan
