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.
Stephan