Change LyX release numbering to Semantic Versioning
José Abílio Matos
jamatos at lyx.org
Wed Jan 13 01:27:21 UTC 2021
On Monday, January 11, 2021 10:58:48 PM WET Joel Kulesza wrote:
> Regarding semantic versioning: I feel like LyX already (arguably) uses that.
> The argument I imagine: it's not clear what prompted moving from version
What is the rationale of the number change?
I have been bugging the mailing list ever since 0.12. :-)
And that worked because we changed to version 1.0 (Feb 1999).
In the case of what prompt the change from version 1 to 2 you can search in
the mailing list. The changed occurred mostly at this time
FWIW this was January-February 2010.
In particular the 1.5 release where we changed to Unicode/UTF-8 it was in a
sense a fundamental change.
> but a Python-based conversion script manages forward/backward
> compatibility in such a way that I regard the "API" as unchanging with the
> various changes that underpin 2.4.0 (maybe I'm mistaken). I would imagine
> a change from 2->3 if, for example, the .lyx file migrated irreversibly
> from what it is now to XML. Otherwise, as JMarc noted once I was already
> composing this, the "API" is pretty stable.
We are, and try very hard to be, backwards compatible, but we are in no way
forward compatible. I have been very clear since the begin of lyx2lyx we
should be able to read perfectly what previous versions LyX version wrote.
If for some reason that does not happen we have a bug.
The conversion of the lyx file format to previous releases works on a best
basis level but there are changes that are impossible to replicate in a
general way. They do work most of the time but it is impossible to have them
work correctly every time. The second law of thermodynamics and the arrow of
FWIW this is the list of API breaks that we had previously is:
The version that I placed is the first release of the cycle.
lyx2lyx appeared after 1.2 and with it we had a way to make a more regular
After that such as it was the first number is irrelevant.
BTW, do you know that at some point the file format was a real number, in the
What I am proposing is to change to a saner and more predictable model, either
the semantic version or the scheme used by several gnu projects, like at least
gcc and octave.
This is similar to the semantic version with one exception. In order to give
an example suppose that we decide to follow that scheme an so the next version
is LyX 3.
The development version, unreleased version is 3.0.0.
As soon as the first test version is released it gets the 3.0.1, the next one
is 3.0.2 and so on.
When the release candidates stage is over and a stable version is released as
If a micro release is required then it goes to 3.1.1.
The usual stable releases that we do will be 3.2, 3.3, 3.4...
In short this scheme is similar to the semver scheme with the exception that
releases where the second number is zero are reserved for development/
What I like in this scheme is that there is no need to place other symbols in
releases to convey its meaning.
More information about the lyx-devel