Hallo Josef, Am Freitag, 10. Februar 2012, 19:45:10 schrieb Josef Latt: > Am 10.02.2012 16:29, schrieb Frieder: > > Am 10.02.2012 15:46, schrieb Josef Latt: > >>> 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 -- Informationen zum Abmelden: E-Mail an users+h...@de.libreoffice.org Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de Listenarchiv: http://listarchives.libreoffice.org/de/users/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
