Re: [libreoffice-marketing] Development will branch off of 7.6 on Jun 5. Please communicate the next version number

On 30/05/2023 10:19, Stephan Bergmann wrote:
> 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/...?

another option would be to have an internal version number that is just 
an integer incremented with every release... a 64-bit integer should be 
enough for 10^18 years of bi-yearly releases... simple and obvious :)


--
To unsubscribe e-mail to: marketing+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/marketing/
Privacy Policy: https://www.documentfoundation.org/privacy