<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif;font-size:large">The year/month scheme is much more honest about what's going on. <br><br>Possibly migrate the 'minor'  version to a datecode and separate it from the major revision number: <br><br>LibreOffice 7.  202404 release. (or 2404) and for bleeding edge (2404.151515) where that's coded date--hh--mm, (there won't ever be a 2nd release within a minute?) ) </div><div class="gmail_default" style="font-family:garamond,serif;font-size:large"><br>You could still list them as a single number 7.2404.151515... but that will in the short term cause a bit of confusion about the sudden drastic increase in revision number. <br><br>This way, the major version represents a major change that affects compatibility, or huge interface swap, or another major app included in the suite... etc. <br><br>But the drum beat releases are "honest" and immediately convey what they are.  </div><div class="gmail_default" style="font-family:garamond,serif;font-size:large"><br></div><div class="gmail_default" style="font-family:garamond,serif;font-size:large">And honestly, I choose software on the date scheme over 'random' numbers. It's easier to keep up with, and shows integrity and traceability and foreplanning all at the same time. </div></div></div>