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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
