Stef wrote
>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.

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.

Focussing improvements in Versioner on releasing more often numbered 
versions is counter productive. It just generates more work to keep 
configurations working. 

I have been fixing lots of configurations on ci, and nearly all problems 
have to do with not using #'releasex.x' style symbolic versioning.
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.

Now Seaside, Grease and Magritte have switched to this style of
versioning, the number of problems has reduced drastically.

Stephan


Reply via email to