> A better solution would be if all developers strictly adhered to Semantic Versioning.
Semantic versioning works well for *libraries*. These tend to have very clearly defined behaviour, inputs and outputs.
I maintain lots of open-source libraries - for dates, languages, algorithms, etc. These all follow semantic versioning.
Semantic versioning doesn't work so well for large and complex *applications*.
There are two types of bug. Firstly, those where the code isn't working as designed. These can be usually be fixed without breaking backwards compatibility.
Secondly, those where the code is working as designed, but the outcome isn't the one that is wanted. Fixing these requires a change in the design - which could potentially break backwards compatibility for someone.
> This also implies a kind of contract: no breaking internal changes are allowed at all when only the last part of the version is incremented.
In any release, there is usually be at least one bug in the second category. So, to follow semantic versioning, we'd need to make every release a "minor version".
Within webtrees, a lot of the code is designed to be extended, replaced, etc. When these interfaces change, it is clearly documented and alternative code is suggested. For example, here's a line in the current code. It says that a function will be removed in the 2.2.0 release, and tells you what to do instead.
github.com/fisharebest/webtrees/blob/7ce...ameTradition.php#L44
Any good PHP development environment will warn you if you use functions marked as "@deprecated", and developers will have plenty of time to update their code to use the new functions..
These interfaces do not change very often. They are also designed so that we usually add to them, rather than change them. So when they do change, most modules will continue to work.
> it is sometimes hard to define what constitutes a breaking change, because custom modules may modify basically any part of the webtrees code.
The vesta modules replace some of the core/internal functions in webtrees - things that were not designed to be modified/extended.
As a result, they are much more sensitive to changes. This creates compatibility errors, which are impossible to catch.
There is no easy solution to this. The current solution requires that somebody (Richard) tests/reviews/updates the code.
But he's offline for a couple of weeks, so you will need to be patient.
Topic Author
