<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 11. Jan. 2021 um 23:59 Uhr schrieb Joel Kulesza <<a href="mailto:jkulesza@gmail.com">jkulesza@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Taking Jose's semver example, I'd alternatively summarize as:</div><div class="gmail_quote"><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div><div><div class="gmail_quote"><p style="margin:0px">So I am proposing for the next version to be 2.4.0.</p></div></div></div><div><div><div class="gmail_quote"><p style="margin:0px">The stable bug fix releases for this series would be 2.4.1, 2.4.2,...</p></div></div></div><div><div><div class="gmail_quote"><p style="margin:0px">If, for instance, there is a problem in the stable version 2.4.2 then we can immediately release version 2.4.3.</p></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br>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.</div></div></div></div></blockquote><div><br></div><div>Just for the records, I do not really care as long as the version does not increase to something bizarre (maybe apply Linus' "no more fingers left to count" rule).</div><div><br></div><div>If we apply Joel's approach, it is well possible that we'll never reach 3.0. At least I hope we won't have changes that are incompatible in the sense that we cannot convert and revert via lyx2lyx. If this doesn't count, any major release is such an incompatible change.<br></div><div><br></div><div>Jürgen<br></div></div></div>