Dear Marketing,
In a few weeks, the next version of LibreOffice will branch off of 7.6,
and gain its new name. Additionally, a release plan needs to be
published imminently. Now is an ideal time for deciding and
communicating what the next version number will be. This also impacts
things like bib
On 26/05/23 12:46, Justin Luth wrote:
It would be nice to have the proper next version number (after 7.6)
ready when master branches in a few weeks, and for the new release plan.
Has that been finalized yet? If not, can we get the decision made before
7.6 branches off? NOW is the appropriate tim
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
On 30/05/23 10:19, Stephan Bergmann wrote:
* 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?
We will announce the change explaining in detail what will happen in the
interi
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
develop
On 5/30/23 5:28 AM, Italo Vignoli wrote:
On 30/05/23 10:19, Stephan Bergmann wrote:
* 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?
We will announce the change explaining
On 30/05/23 13:57, Justin Luth wrote:
Italo, you have now communicated two different names for the "new"
process. Originally you said it was "24.2", but here you have noted it
as 2024.2. Please clarify.
I don't see any problem whatsoever with the shorter 24.2. I'm quite sure
the project will
Hi
Am 30.05.23 um 10:54 schrieb Michael Stahl:
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 😄
Why not just use the build ID as i