On 23-06-15 15:17, Nicolas Anquetil wrote:

we walked in the office one day and our system was broken because of some change in petitParser.

That should have been a new symbolic release. And that was clear from the breaking builds on CI.

The same thing happenned with roassal and other libraries.
We are not always (rarely) in a position where we can fix our code to keep working with the new version of the libraries we use.

That is where the symbolic versioning of Seaside works rather well.

This does not mean the developers are not good, it is just that they evolve their stuff according to their needs and our needs are not the same.

So our solution is to rely on static revision numbers that are known to work.
From time to time, when we are ready, we do the work to update to a new version of the libraries.
That might work for you because you don't have anyone using your configurations.
For configurations that are used by other projects, that results in impossible combinations
of version numbers.

This saves us a lot of time and even more troubles.

Depending on symbolic names like "stable" is no good because the stable revision also moves, and not always when we are ready for it.

Depending on symbolic names like #'release3.1' works very well.
We get the bug fixes and non-breaking changes. #stable works
well for projects that do only bugfixes. Of course it only works as well
as the maintainers of the dependencies update their configurations.

This is not true for everything, moose for example tends to be much more stable that Roassal which evolves at a fast pace.
PetitParser evolves more slowly too, but for a long time, there has been a change in it which we could not leave with (not sure what is the status currently)

The PetitParser context change should have been a release.