Hallo Josef,
>>> Das ist ein bekannter Bug in der Version 3.4.x. ( In der gesamten
>>> Reihe.)
>>> In der Version 3.5.x ist dieser Bug bereits behoben.
>>> Da ich dir aber nicht empfehlen kann die 3.5.er Version
>>> in einem so frühen Stadium der Entwicklung zu nutzen,
>>
>> Früh? Es gibt ja schließlich schon den RC3 und die Final solls noch im
>> Februar geben.
>
> Eine RC ist nur ein veröffentlichungs- Kandidat, und noch keine Fertige
> Version.
> Und selbst eine Version X.X.0 oder X.X.1 hat oft noch zu viele
> gravierende Bugs,
> so dass sie für den Produktiven Einsatz nicht zu empfehlen ist.
> Schau dir doch einfach die Bugliste auf Bugzilla für die Version 3.5.x
> an.
>
> (2346 Treffer Bei der Suche)
Es gibt auch noch jede Menge Bugs früherer Versionen.
> unter einer späten Version verstehe ich z.B. eine X.X.4 oder X.X.5
>
> Aber leider ist selbst das kein Garant dafür,
> das die Version auch wirklich für den Produktiven Einsatz geeignet ist.
> (zumindest bei der 3,4er Reihe)
Wenn die 3.5 als Final rauskommt, muß sie IMHO auch für den produktiven
Einsatz geeignet sein, sonst kann man das lassen. Aber man will ja wohl
den Release-Zyklus einhalten.
Da gibt es offensichtlich verschiedene Ansichten.
Es gibt aber nur *einen* Release-Plan für LibreOffice, und der ist festgelegt,
zumindest für die nächste Zeit! Ich glaube nicht, dass es besonders hilfreich
ist, immer wieder darüber zu jammern, dass er nicht den eigenen Vorstellungen
entspricht.
Dieser Releaseplan sieht nun mal zeitlich festgelegte Minor-Releases mit
häufigen Bugfix-Releases vor, d.h. wir haben nun mal diese - wie soll man das
nennen - zeitlich strikt festgelegte "Entlassung" des Codes aus dem
Entwicklerbrutkasten, was vielleicht manchem irgendwie gegen den Strich geht,
aber das wird dann durch eine "forcierte Nachreifung" sozusagen wieder wett
gemacht.
Josef, jetzt jammer doch nicht über Dinge, die nun mal so festgelegt wurden,
sondern versuche lieber den besten Nutzen daraus zu ziehen 
Mir persönlich leuchtet zwar das große Potential dieser zeitgesteuerten
Vorgehensweise rein theoretisch durchaus ein, aber ich habe gleichzeitig ein
recht mulmiges Gefühl bezüglich der Codequalität bekommen, hauptsächlich weil
die 3.4-Reihe am Anfang sehr buggy war (keine Ahnung ob sie das immer noch
ist, ich nutze schon seit einiger Zeit schon die 3.5-Vorversionen).
In meinen Augen kann dieser Weg also durchaus für alle von Nutzen sein, aber
das erfordert nun mal, dass man sich a) mit dem Reifegrad (=Microreleases) des
Codes gut auskennt und b) über die eigenen Wünsche und Bedürfnisse ins Klare
kommt: Will ich lieber reiferen, stabileren Code oder nehme ich etwas mehr
Probleme in Kauf, wenn ich dafür bestimmte Features kriege. Da heißt es, sich
informieren, Releasenotes lesen, abwägen, testen.
Denn in der Praxis hat man doch überwiegend "seine" Anwendungsfälle, für die
man die Software produktiv einsetzt, d.h. die sollten wirklich funktionieren,
sonst macht es ziemlich wenig Spaß.
Ich sehe da wirklich nur den Weg, so weit "vorne" wie möglich mitzutesten, um
die gewünschte Funktionalität abzuprüfen und Ausfälle den Entwicklern
möglichst früh um die Ohren zu hauen 
Von alleine entdecken sich die Bugs
nicht! Und bei etlichen Bugs ist ja wohl auch die Eskalation auch schief
gegangen, d.h. sie liegen seit Monaten im Bugzilla unbemerkt herum. Das heißt,
für uns alle ist noch viel Verbesserungspotential da, eine Chance, die wir
nutzen sollten
Schönen Gruß
Nino
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}