On 5/27/23 23:13, Italo Vignoli wrote:
The next major release after LibreOffice 7.6 will be LibreOffice 24.2
(February), which will be followed by LibreOffice 24.8 (August)
* Given the current level of maturity of the LibreOffice Technology
development platform, it is increasingly difficult to provide a number
of significant new features for each major release based on the current
numbering scheme (while new features are key for media coverage, if we
maintain the current numbering scheme)
* By choosing a calendar based numbering scheme, we decouple the
expectation of significant new features from each new major release: if
we have significant new features they will be welcomed by the media, but
if we don't have them the media will not be disappointed (and will write
about LibreOffice)
* We have already started to adapt our communication strategy to the new
numbering scheme by meeting journalists independently from announcements
* At LibreOffice Conference we will provide additional information about
the communication strategy, and how this will help increasing the update
frequency by users (which is now rather low, apart from a very small
percentage of users)
This raises two questions:
* How does the new versioning scheme fit with the current setup of
having two parallel streams of "fresh" (currently LO 7.5.3) and "still"
(currently LO 7.4.7) versions?
* Some places in the code rely on version numbers being strictly
monotonically increasing based on a lexicographical ordering of their
dotted version number segments. (For example, 7.4.6 < 7.4.7 < 7.5.3 <
8.0.) Switching to a 24.2/24.8/... versioning scheme would initially
fit that requirement (as 7.6 < 24.2). But the two-digit year component
of that scheme has the disturbing (to pedants, at least) issue of
wrap-around. Can we instead use a full-year versioning scheme,
2024.2/2024.8/...?
