<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jan 11, 2021 at 2:18 PM Richard Kimberly Heck <<a href="mailto:rikiheck@lyx.org" target="_blank">rikiheck@lyx.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>On 1/11/21 3:59 PM, José Abílio Matos
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p style="margin:0px">Today
        in the virtual meeting we discussed several of the issues
        regarding the next major version for the stable release.</p>
      <br>
      <p style="margin:0px">I
        am proposing here to change to a Semantic Versioning scheme.
        This can is best described here:</p>
      <p style="margin:0px"><a href="https://semver.org/" target="_blank">https://semver.org/</a> </p>
      <br>
      <p style="margin:0px">So
        I am proposing for the next version to be 3.0.0.</p>
      <br>
      <p style="margin:0px">The
        stable bug fix releases for this series would be 3.1.0,
        3.2.0,...</p>
      <br>
      <p style="margin:0px">If,
        for instance, there is a problem in the stable version 3.2.0
        then we can immediately release version 3.2.1.</p>
      <br>
      <p style="margin:0px">Since
        we our release schedule is every two years this will keep us in
        low numbers for a long time.</p>
      <br>
      <p style="margin:0px">What
        do you think?</p>
    </blockquote>
    <p>I would like to hear from Joel about this. Apparently, these
      numbers matter to some people.</p>
    <p>Riki</p></div></blockquote>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:0 0 0 40px;border: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 class="gmail_quote"><br></div><div class="gmail_quote">Thank you,</div><div class="gmail_quote">Joel</div></div></div></div>