#LibreOffice 24.2 will be our next major update, coming in February! 🎉 (New versioning scheme, to show the year and month when it's released.) A big new feature is styles for comments, added by Maxim Monastirsky: wiki.documentfoundation.org/Re… #foss #OpenSource
But it's the same – LibreOffice 7.6 (big number, smaller number) becomes 24.2. The release schedule is staying the same. Nothing changes in how we make the software, but the version numbers now reflect the year and month the software was released, rather than being just arbitrary X.X numbers.
Ah OK, we see what you mean. LibreOffice will continue to have two big updates a year (plus many small revisions), so that doesn't change. The big number will be fixed to the year so we can't change that for a huge "generation" update, yes. But the software is also mature now after 12 years of development so we think this is a better approach. Good to have feedback though...
Not maintenance – as mentioned, we'll have two big updates every year, with lots of new features, exactly the same as now. Nothing changes in the release engineering.
Re: the other point, it's not about advertising. Many people are using old versions of LibreOffice, and having a year+month version number (and communicating that well) can help. For the vast majority of end users, that year+month number says more than just some arbitrary thing that we choose. That's our view anyway 😊
This is a valid point... information to end users... but what about information to engineers and administrators? Something to offer both?
And hopefully, the version number was never "arbitrary"... it should tell me, that for example 7.6 is the seventh generation as seventh minor update (including six minor updates). Indicates also some maturity...
Btw.: I still have 6.4.x here... on a Linux LTS...
Oh sure, it was never arbitrary for us – but for the vast majority of end users, who aren't familiar with release schedules, version numbering systems etc., "7.6" doesn't say much.
And you're right about keeping sysadmins and engineers in the loop, so any changes in those contexts will be clear in our announcements, release notes and other places. But please do let us know if we can improve something! 😊
Funny... for me you start now with arbitrary numbers... 😉
What about using something like "Edition 2023, Version 7.6"?
And btw. i assume, it is possible to develop add-ons for #LibreOffice... how do they check a matching version? As something like "works with 7.x" (checking on major version 7 in the source code) would be no longer possible, right?
And are you sure, that end users will recognize 24.2 as February 2024? 😉
It also doesn't say anything about the degree of change I can expect as a user. If I upgrade from, say, 7.1 to 9.3, I know I can expect some fairly large changes. If I upgrade from 23.11 to 24.1 in a date-based versioning scheme? No idea. Maybe 23.11 was a maintenance release only fixing a security issue in 22.7, and 24.1 is a new major release?
Date-based version numbers might work for collections of software. For a single product, though, it quickly becomes confusing.
Right, but the vast majority of our end users don't know what version numbers mean, so going from eg 7.1 to 9.3 doesn't say anything to them. Using year.month gives them a bit more context. We've done research and listened to our users, and many want this.
Of course, others won't be happy. Any time we make any change, some people are happy, some not. Version numbers don't just exist in a vacuum, and we'll provide more context about the degree of change in our announcements.
great feature! please make sure that it looks as flashy as it can in default settings, for example padding around text, use colors that look good together and so on, it makes a huge difference! thanks to the dev in advance
@_peteraaaa Cheers! Feel free to add your feedback to the ticket at bugs.documentfoundation.org/sh… – And if you can help our volunteers to work on it, even better 😊
I just found out about the new version numbering being YY/M. It will make it easier to know how old your installed release is, and decide whether it's a good moment to update. 👍
@Schimmelreiter Just like now, one number will be bigger than the other. LibreOffice 7.6 is newer than LibreOffice 7.5, and LibreOffice 24.8 will be newer than LibreOffice 24.2.
@Schimmelreiter Ah right – yes, when we release LibreOffice 24.2 in February, LibreOffice 7.6 will be the older maintained branch. So there'll be a bit of overlap where both version numbers are used.
@Schimmelreiter I guess it will actually be 24.2.0 for the major update release, then 24.2.1, 24.2.2… every 6 weeks for security and minor updates as it is until now.
@TritTriton @Schimmelreiter Yes! Nothing will change in the release engineering and schedule – just that the version numbers now say something about when the software was released, to add some context.
Flávio Oliveira
in reply to LibreOffice • • •Nordnick 🐘
in reply to LibreOffice • • •LibreOffice
in reply to Nordnick 🐘 • • •Nordnick
in reply to LibreOffice • • •It's not the same... it is major.minor compared to year.month... the date of the release is telling nothing about the version.
Is 24.2 just a minor update (like 7.7) or a new major generation (like 8.0)?
LibreOffice
in reply to Nordnick • • •Nordnick
in reply to LibreOffice • • •Thanks for replying.
I like to have version numbers, that includes information to an engineer.
I don't like version numbers, that are just used for advertising purposes.
en.wikipedia.org/wiki/Software…
semver.org/
And btw. "mature"... does that mean, you will now switch to maintenance only?
Semantic Versioning 2.0.0
Tom Preston-Werner (Semantic Versioning)LibreOffice
in reply to Nordnick • • •Not maintenance – as mentioned, we'll have two big updates every year, with lots of new features, exactly the same as now. Nothing changes in the release engineering.
Re: the other point, it's not about advertising. Many people are using old versions of LibreOffice, and having a year+month version number (and communicating that well) can help. For the vast majority of end users, that year+month number says more than just some arbitrary thing that we choose. That's our view anyway 😊
Nordnick
in reply to LibreOffice • • •Two new generations a year?
This is a valid point... information to end users... but what about information to engineers and administrators? Something to offer both?
And hopefully, the version number was never "arbitrary"... it should tell me, that for example 7.6 is the seventh generation as seventh minor update (including six minor updates). Indicates also some maturity...
Btw.: I still have 6.4.x here... on a Linux LTS...
LibreOffice
in reply to Nordnick • • •Oh sure, it was never arbitrary for us – but for the vast majority of end users, who aren't familiar with release schedules, version numbering systems etc., "7.6" doesn't say much.
And you're right about keeping sysadmins and engineers in the loop, so any changes in those contexts will be clear in our announcements, release notes and other places. But please do let us know if we can improve something! 😊
Nordnick
in reply to LibreOffice • • •Funny... for me you start now with arbitrary numbers... 😉
What about using something like "Edition 2023, Version 7.6"?
And btw. i assume, it is possible to develop add-ons for #LibreOffice... how do they check a matching version? As something like "works with 7.x" (checking on major version 7 in the source code) would be no longer possible, right?
And are you sure, that end users will recognize 24.2 as February 2024? 😉
mkj
in reply to Nordnick • • •It also doesn't say anything about the degree of change I can expect as a user. If I upgrade from, say, 7.1 to 9.3, I know I can expect some fairly large changes. If I upgrade from 23.11 to 24.1 in a date-based versioning scheme? No idea. Maybe 23.11 was a maintenance release only fixing a security issue in 22.7, and 24.1 is a new major release?
Date-based version numbers might work for collections of software. For a single product, though, it quickly becomes confusing.
LibreOffice
in reply to mkj • • •Right, but the vast majority of our end users don't know what version numbers mean, so going from eg 7.1 to 9.3 doesn't say anything to them. Using year.month gives them a bit more context. We've done research and listened to our users, and many want this.
Of course, others won't be happy. Any time we make any change, some people are happy, some not. Version numbers don't just exist in a vacuum, and we'll provide more context about the degree of change in our announcements.
david petera
in reply to LibreOffice • • •LibreOffice
in reply to david petera • • •103064 – Introduce a comment style
bugs.documentfoundation.orgLibreOffice
Unknown parent • • •LucasVieites
in reply to LibreOffice • • •LibreOffice reshared this.
LibreOffice
Unknown parent • • •LibreOffice
Unknown parent • • •Trit’
in reply to LibreOffice • • •LibreOffice
in reply to Trit’ • • •