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
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
So our solution is to rely on static revision numbers that are known
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
For configurations that are used by other projects, that results in
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.