Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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
> 1->2,

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
https://marc.info/?l=lyx-devel&m=126510457111147&w=2

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 
the time...


FWIW this is the list of API breaks that we had previously is:

...
0.6.0
0.8.0
0.10.0
0.12.0
1.0.0
1.1.0
1.1.5
1.1.6.0
1.1.6.3
1.2.0
1.3.0
1.4.0
1.5.0
1.6.0
2.0.0
2.1.0
2.2.0
2.3.0

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

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 
bank format?

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 
LyX 3.1.
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/
stabilizing versions.

What I like in this scheme is that there is no need to place other symbols in 
releases to convey its meaning.

-- 
José Abílio