Re: [de-users] Neue Release-Bezeichnungen LO 24.2.X nach LO 7.6.X

Am Donnerstag, dem 02.11.2023 um 12:53 +0000 schrieb Hans-Werner Herold:

> [1] Der Absatz »[...] Es hat sich gezeigt, dass ... vielleicht zweiten 
> Nebenpunktversion aufzuschieben. [...]« erscheint 2 mal wortwörtlich.

Das ist auch auf der englischen Originalseite der Fall.
Wurde dann eben einfach durch den Übersetzer geschickt.

> [2] Diese Formulierung »[...] Wenn Sie also einen Bedarf an der 
> allerhöchsten Qualitätsversion haben, kann es sinnvoll sein, einen Umzug 
> bis zur ersten oder vielleicht zweiten Nebenpunktversion 
> aufzuschieben.[...]« empfinde ich nicht sehr hilfreich - ehrlich gesagt 
> eher als »WischiWaschi«: »[...] kann es sinnvoll sein, einen Umzug bis 
> zur ersten oder vielleicht zweiten Nebenpunktversion aufzuschieben.

Erfahrungsgemäß werden in den ersten, erscheinenden Patchreleases die meisten
schwereren Fehler behoben. Von daher kann es durchaus sinnvoll sein mit einem
Versionssprung vorerst zu warten.

> [...]«. Im operativen (Geschäfts-/Behörden-) Umfeld ist eine klare und 
> eindeutige Ansage von Nöten, nicht aber ein »kann« oder »vielleicht«.

Du weißt schon, warum der Zusatz "Community" im LibreOffice-Paket eingeführt
wurde?

> Bezüglich »[...] Die erste X.Y.0-Version ist für Erstanwender gedacht. 
> Konservativeren Benutzern wird empfohlen, auf eine spätere 
> X.Y.Z-Fehlerbehebungsversion zu warten. [...]« will man wissen, wie viel 
> später. Diese Entscheidung kann man doch nicht auf den Endbenutzer (im 
> operativen Umfeld) abwälzen.

Doch. Kann man. Oder bist Du hierfür noch nicht mündig genug?

Ein Nutzer / eine Nutzerin wissen selber besser Bescheid darüber, ob sie eine
möglichst neue Version von LO nutzen möchten oder benötigen. Ist dies der
Fall, so würde ich einem entsprechendem Anwender bspw. empfehlen auf die
zweite Patchversion zu warten. Das wäre auf, das neue Versionsschema
umgemünzt, Version 24.2.2.

Möchte der Anwender / die Anwenderin hingegen eine recht stabile und Fehler
befreite Version, dann würde ich die jeweils aktuelle "Still" Version
empfehlen.

> [3] SORRY, ich habe keinen Bedarf an »allerhöchsten Qualitätsversion«, 
> ich habe konkret Bedarf an »allerhöchster Fehlerfreiheit« und 
> »allerhöchster Kontinuität« in dem Sinne, das meine erstellten 
> LO-Dokumente auch nach einem LO-Update noch »funktionieren«.

Genau diese, von Dir hervorgebrachten Punkte "allerhöchste Fehlerfreiheit" und
"allerhöchste Kontinuität" würde ich unter dem Punkt "allerhöchste Qualität"
zusammenfassen.

> [4] Ich habe grundsätzlich nichts gegen die neue Release-Bezeichnung. 
> Bei der alten Release-Bezeichnung war es einfach und dadurch auch - im 
> Rückblick - bezüglich Fehlerfreiheit recht stabil:
>
> 7.5.X = STILL und 7.6.X = FRESH - nach Zyklus-Ablauf - 7.6.X = STILL + 
> 7.7.X = FRESH - nach Zyklus-Ablauf - 7.7.X = STILL + 7.8.X = FRESH ...
>
> Um eine vergleichbare Einfachheit bei der neuen Release-Bezeichnung zu 
> haben, hätte ich gern ein KLARE UND EINDEUTIG EMPFEHLUNG und kein »kann« 
> und/oder »vielleicht«, wenn ich für den Einsatz von LO im operativen 
> Umfeld verantwortlich wäre.

Hier ändert sich doch gar nicht so viel. Künftige Releases werden alle 6
Monate erscheinen.

Nach der jetzigen 7.6er-Version kommt im Februar kommenden Jahres Version
24.2.0 nach dem neuen Versionsnummernschema. Das ist dann die neue "Fresh"
Version, während die 7.6.x dann zur neuen "Still" Version wird.

Im September kommt 24.9.0 als "Fresh", 24.2.x wird "Still". Und so setzt sich
das fort.

Patchreleases erscheinen auch recht regelmäßig. Hier erkenne ich keinen
nennenswerten Unterschied zum bisherigen Vorgehen.

> [5] Im Großen und Ganzen habe ich den Eindruck, dass die 
> LO-Weiterentwicklung »mehr fließend« sein wird, damit wird aber wohl 
> auch die Fehlerfreiheit »fließender« sein. Okay, kein Problem.

Etwas fließender und an die Veröffentlichungszyklen anderer OpenSource-
Projekte besser angepasst.

> Aber dann sollte man vielleicht mal ernsthaft darüber nachdenken, LO für
> ALLE (unterstützten) BETRIEBSSYSTEME eine professionelle und einfache 
> FALLBACK - oder PARALLEL-INSTALLATION - Funktionalität zu spendieren, 
> die Teil der LO-Distribution ist. Für einen verantwortlichen 
> Administrator im operativen Umfeld ist das Wichtigste, das nach einem 
> LO-UPDATE in den bereits vorhandenen LO-Anwendungen auf einmal KEINE 
> Fehler auftreten - und wenn doch, er schnell auf die vorherige 
> LO-Version downgraden kann.

So etwas ist bereits möglich. Siehe [1].

Unter Linux kann man alternativ auch verschiedene Programmversionen parallel
via AppImage, Flatpak oder Snap installieren.

1: <https://wiki.documentfoundation.org/Installing_in_parallel/de>

-- 
MfG Richi


-- 
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy