Change LyX release numbering to Semantic Versioning
jkulesza at gmail.com
Mon Jan 11 22:58:48 UTC 2021
On Mon, Jan 11, 2021 at 2:18 PM Richard Kimberly Heck <rikiheck at lyx.org>
> On 1/11/21 3:59 PM, José Abílio Matos wrote:
> Today in the virtual meeting we discussed several of the issues regarding
> the next major version for the stable release.
> I am proposing here to change to a Semantic Versioning scheme. This can is
> best described here:
> So I am proposing for the next version to be 3.0.0.
> The stable bug fix releases for this series would be 3.1.0, 3.2.0,...
> If, for instance, there is a problem in the stable version 3.2.0 then we
> can immediately release version 3.2.1.
> Since we our release schedule is every two years this will keep us in low
> numbers for a long time.
> What do you think?
> I would like to hear from Joel about this. Apparently, these numbers
> matter to some people.
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, 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.
Taking Jose's semver example, I'd alternatively summarize as:
So I am proposing for the next version to be 2.4.0.
The stable bug fix releases for this series would be 2.4.1, 2.4.2,...
If, for instance, there is a problem in the stable version 2.4.2 then we
can immediately release version 2.4.3.
So, this is effectively how things operate now except collapsing the fourth
entry into the third. Once a breaking change occurs, then the jump would
be made from 2->3.
Regarding how these numbers might matter to someone: I've had experience
with organizations that approve software for use based on major version
number. So, changing major version number can require re-review for use,
which inhibits adoption/continued use. This is not insurmountable, and
it's a very unique and bizarre concern; however, I did want to raise it as
an issue and why I'm not too enthusiastic about rapid version number
changes. That said, my belief is that numbers are straightforward to count
and arbitrary anyway, so rapid incrementation doesn't bother me personally.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lyx-devel