Link alla notizia: http://www.hwfiles.it/news/rilasciato-libreoffice-343-la-versione-per-le-aziende_38291.html

The Document Foundation rende disponibile LibreOffice 3.4.3 a distanza di poche settimane dal precedente rilascio


Click sul link per visualizzare la notizia.

Scusate ma perchè è definita "per aziende"?
Perchè è a pagamento?
Poi che vuol dire che la versione 3.3.4 è per gli utenti più prudenti? La versione 3.4.3 non è stabile ma è una beta?
Qualche dettaglio in più non sarebbe stato tanto sbagliato...

E' definita "per aziende" perché il suo livello di maturità è ritenuto adeguato per l'adozione in un ambiente di produzione aziendale.

Devo averlo letto in giro da qualche parte (forse sullo stesso sito web di LibreOffice) che le release "adatte" ad un impiego aziendale sono considerate quelle dal terzo rilascio in poi per una data "mayor release", quindi quelle con numero di versione >= x.x.3.

Per la release 3.3, la versione 3.3.4 è in pratica il quarto rilascio, quindi ha subìto un consistente lavoro di pulizia da problemi/bachi/ecc.: non è più la release più recente, ma è considerata molto robusta per quanto dicevo poco sopra e quindi indicata per gli utenti più "conservativi", cioè quelli che sono disposti a rinunciare alle versioni più recenti ed innovative per privilegiare l'affidabilità.

Ciao
Filippo

grazie del chiarimento!

anch'io in effetti mi domandavo quale fosse la differenza tra i due rami.. forse, adesso che sono giunti a un rilascio stabile del filone 3.4, mi aggiornerà anche quella su ubuntu da ppa..

Non capisco il grafico. La 3.4.3 sembra cosìcosì e nel contempo stabile, molto stabile e rock solid. :confused:

Grazie per il chiarimento omonimo :)

La definizione che usano per le "aziende" in effetti fa più pensare a versioni precedenti non stabili o cmq non affidabili, insomma le classiche release tanto per dire "è uscita quella nuova"...a questo pensiero poi ti ci porta anche la frequenza degli aggiornamenti, sempre più vicini l'uno con l'altro.
Cmq ho provato questa nuova versione e non mi funziona più il correttore ortografico.

La definizione che usano per le "aziende" in effetti fa più pensare a versioni precedenti non stabili o cmq non affidabili, insomma le classiche release tanto per dire "è uscita quella nuova"...a questo pensiero poi ti ci porta anche la frequenza degli aggiornamenti, sempre più vicini l'uno con l'altro.
Cmq ho provato questa nuova versione e non mi funziona più il correttore ortografico.
Ne stiamo giusto discutendo nel thread ufficiale LibreOffice [thread ufficiale] (http://www.hwupgrade.it/forum/showthread.php?t=2309989) nelle ultime pagine.

Ne stiamo giusto discutendo nel thread ufficiale LibreOffice [thread ufficiale] (http://www.hwupgrade.it/forum/showthread.php?t=2309989) nelle ultime pagine.

Avevo gia visto, ma avendo fatto l'installazione personalizzata il dizionario c'era, ho provato a reinstallarlo, ma non è cambiato nulla...ora cmq ho rimesso la versione 3.3...mi sa che per passare alla 3.4 aspetterò che esca la 3.5, inizierò a fare come le aziende che si tengono sempre una versione indietro :D.
Cmq la qualità di libreoffice lascia un po a desiderare, rilasciano molte versioni, ma con troppi problemi, inizio quasi a rimpiangere il vecchio openoffice.

@andy45
Quello del mancato riconoscimento dei dizionari dopo un aggiornamento è un bug clamoroso che si trascina da tempo, ma per il quale c'è una soluzione semplice. Vedere la segnalazione ufficiale del bug:

https://bugs.freedesktop.org/show_bug.cgi?id=37195#c24

In ogni caso LibreOffice ha dei seri problemi di sviluppo, e richiede agli utenti una dose di fiducia che attualmente non è in grado di assecondare. Se non cambia qualcosa in profondità non vedo possibilità di miglioramento per il futuro.
Vedremo se e come si svilupperà Apache OpenOffice...

Saluti
VITRIOL

@andy45
Quello del mancato riconoscimento dei dizionari dopo un aggiornamento è un bug clamoroso che si trascina da tempo, ma per il quale c'è una soluzione semplice. Vedere la segnalazione ufficiale del bug:

https://bugs.freedesktop.org/show_bug.cgi?id=37195#c24

Grazie della segnalazione, appena ho un po di tempo provo.

In ogni caso LibreOffice ha dei seri problemi di sviluppo, e richiede agli utenti una dose di fiducia che attualmente non è in grado di assecondare. Se non cambia qualcosa in profondità non vedo possibilità di miglioramento per il futuro.

Io di programmazione non ne capisco nulla, cmq rilasciare cosi tanti aggiornamenti in breve tempo non mi sembra una buona strategia, meglio pochi ma ben fatti...capisco che avevano promesso una brusca accelerazione dello sviluppo, però non a scapito della qualità.

Vedremo se e come si svilupperà Apache OpenOffice...

Vediamo, per ora è ancora tutto allo stato embrionale, quindi bisognerà aspettare per un bel po.

Stando al sito di LibreOffice, l'ultima versione stabile è ancora la 3.3.4 ("Questo è il quarto aggiornamento alla versione stabile di LibreOffice. Contiene solo correzioni al codice ed aggiornamenti delle traduzioni, ed è considerata sicura per l'utilizzo in produzione. Potete anche leggere le note di release e le nuove funzionalità in questa versione."); mentre la 3.4.3 è definita "utilizzabile per esigenze di produzione dalla maggior parte degli utenti e dalle aziende" ma non è considerata "stable".
http://it.libreoffice.org/download/

mentre la 3.4.3 è definita "utilizzabile per esigenze di produzione dalla maggior parte degli utenti e dalle aziende" ma non è considerata "stable".

Il problema è in questo, se rilasci una versione definitiva di un programma allora deve essere considerata "stabile" (inteso come affidabile per tutti gli utilizzatori), se questa non lo è, allora non è una versione definitiva.

L'indicare che è uscita una versione utilizzabile anche dalle aziende poi implica che questa sia al 100% affidabile (e quindi stabile), ma se poi affermano che la versione stabile è la 3.3.4, allora c'è qualcosa che non quadra...se stabile sarà la versione 3.4.4, allora le 3.4.0, 3.4.1, 3.4.2 e 3.4.3 come vanno considerate? Se loro stessi non le definiscono versioni stabili allora cosa sono?

Per come la vedo io hanno creato solo due "linee" diverse, una sperimentale (per ora la 3.4) ed una definitiva (per ora la 3.3), ma la sperimentale non potrà essere considerata definitiva finchè non esce la successiva versione sperimentale (in questo caso la 3.5)...quindi se uno vuole la versione definitiva di libreoffice deve scaricare la 3.3, se vuole fare da "tester" nella versione sperimentale scarica la 3.4.

Presentarsi così ad un'azienda è il modo più facile per farli restare con la suite che hanno usato finora...

Il problema è in questo, se rilasci una versione definitiva di un programma allora deve essere considerata "stabile" (inteso come affidabile per tutti gli utilizzatori), se questa non lo è, allora non è una versione definitiva.

Purtroppo vorremmo tutti che fosse vero che "stabile" = "100% affidabile", intendendo con questo l'equivalente di "bug free". Nella pratica però questo risultato non è conveniente da perseguire. Per cui ogni organizzazione che sviluppa software si costruisce la sua propria definizione di "stabile", basata su considerazioni di carattere statistico (già è estremamente gravoso, per un software complesso come può essere una suite di office automation, il solo fatto di verificare esaustivamente tutte le possibili funzionalità offerte, figurarsi poi il garantire che siano tutte bug free).

Nel caso di LibreOffice, probabilmente (è una mia ipotesi) avranno stabilito che, statisticamente, le release x.y.3 siano sufficientemente stabili da essere utilizzabili in ambito di produzione, e le x.y.4 siano particolarmente robuste da essere preferibili per chi cerca l'affidabilità sopra ogni altra cosa.

Tra parentesi, a casa uso la versione 3.4.0 (quindi il primo rilascio della serie 3.4) e francamente per il (blando) uso che ne faccio non ho trovato svarioni.

Ciao
Filippo

Rock solid = Old Stable
Very Stable = Stable
Stable = Testing
Bleeding Edge = Unstable
Developer = Experimental

Modello testato e ultra collaudato (poi rinominiamolo pure come preferiamo). La politica mi piace e mi soddisfa, con Debian mi sono trovato sempre benissimo con questo approccio.
Numeri di release ed altro creano solo confusione.
Vedetela così: ogni qualvolta modifico una riga di codice posso creare dei bug. Per aggiungere la funzionalità "Uomo ragno" devo modificare molte righe di codice e quindi il codice è molto instabile dopo la sua introduzione ma i bug sono molto semplici da individuare dato che sono macroscopici (basta il debugging dello sviluppatore stesso) - siamo al livello Developers.
Quando le righe di codice modificate per aggiungere la funzionalità "Uomo ragno" sono considerate pronte per l'utente smanettone allora il codice viene posto in Bleeding Edge senza introdurre ulteriori modifiche (niente novità! ho sempre e solo la nuova funzionalità "Uomo ragno" ma il codice è ora più stabile).
L'utente smaliziato comincia ad usare la nuova funzionalità conscio del fatto che potrebbero esserci dei bug e così aumenta la base di debugging e quindi aiuta i "pochi" sviluppatori ad individuare ulteriori bachi in punti particolari e permette un ulteriore raffinamento del codice che viene quindi consolidato.
Dopo un periodo in Bleeding Edge, quando non ci sono più segnalazioni da parte degli smanettoni, il codice modificato che include la funzionalità "Uomo ragno" sarà considerato Stabile.
A questo punto sviluppatori e smanettoni stanno già da tempo rodando il codice quindi le garanzie che sia stabile sono sufficienti.
La base di debugging si allarga quindi ancora una volta esponenzialmente. Il debugging è ulteriormente approfondito ed il codice modificato per inserire l'"Uomo ragno" viene messo a dura prova con centinaia di migliaia di utenti che sfruttano tutte le funzioni all'osso.
Passato un tempo ragionevole (e qualche fix minore) il codice con l'"Uomo ragno" passa in Very Stable (quella plausibilmente utilizzata dalle aziende).
Il campo aziendale è il più tosto in assoluto. Qui non sono ammessi errori e malfunzionamenti. L'amministratore di sistema vuole garanzie e l'utenza deve produrre reddito ininterrottamente anche con la funzionalità più assurda e con le combinazioni più esagerate.
Ecco perchè il codice dell'"Uomo ragno" che supera questa fase è detto Rock Solid: semplicemente perché è da tempo che nell'utilizzo più massivo non si riscontrano problemi ed è già pronta un altra versione considerata Very Stable (questa volta con l'"Uomo ragno" e la nuova feature "Donna topa"). Il codice modificato per la "Donna topa" ha già passato tutti gli step rimanendo sempre un passo indietro rispetto all'"Uomo ragno" perchè la funzionalità è stata aggiunta più tardi.

L'approccio funziona molto bene e consente anche una certa versatilità. Permette di raffinare gradualmente il software e le sue funzionalità portandolo da una piccola base di testing molto ristretta (100 sviluppatori) ed una enorme base di utenza (100 milioni di utenti business) attraverso fasi intermedie di revisione ed ispezioni di qualità perché un pezzo di codice scende di livello solo quando il tempo, l'utenza e gli sviluppatori hanno decretato che è pronto per il salto.
In questo modo lo sviluppo non si blocca ad una ipotetica versione "stabile" da rilasciare, ma "fluisce" senza interruzioni dall'instabile (refactoring e nuove feature) all'ultra-stabile (codice ultra-collaudato ma con meno feature).
Utenti ed aziende possono quindi scegliere.
Massima stabilità o ultime feature a disposizione?
Cerco di scegliere la versione corretta per la mia realtà in base all'utilizzo che ne faccio ed in base alla sua criticità. Se la Very Stable ha tutto quello che mi serve allora sicuramente metterò quella nella mia azienda. A casa è meno importante la stabilità, magari metterò la Stable per giocherellare con qualche ultima novità.
Se poi mi serve proprio una versione recentissima, perchè mi serve la "Donna topa" con il plugin "Nuda e rovente" allora prenderò la Bleeding edge, sapendo però che potrei restare scottato!

E' normale essere un po' in difficoltà di fronte a questa politica perché ci mette di fronte ad una scelta. Ma come si dice nel mondo open "la possibilità di scegliere è libertà".

A casa è meno importante la stabilità, magari metterò la Stable per giocherellare con qualche ultima novità.

Mica è vero, anche a casa la stabilità è importante...e cmq Stable = Testing non vuol dire assolutamente "stabile da essere usato nella maggior parte delle aziende", stabile da poter essere usato dalle aziende equivale a "rock solid = old stable"...programmi esenti da bug non esistono e mai esisteranno, però se un'azienda vuole migrare a libreoffice, si trova di fronte un programma definito stabile per l'uso aziendale, andando a fare i dovuti test viene fuori che il programma non è stabile manco per niente, scusami ma a libreoffice non ci passano neanche se gli spari...e ci penseranno sopra 10 volte prima di ritentare la migrazione.

E' normale essere un po' in difficoltà di fronte a questa politica perché ci mette di fronte ad una scelta. Ma come si dice nel mondo open "la possibilità di scegliere è libertà".

Il problema non è la scelta, è come viene definito il programma, un programma che non è ancora realmente stabile non può essere definito "per le aziende"...gia io con le nomenclature che hai usato difficilmente userei una versione "testing", ma andrei su una più cauta "stable"...e sono un normale utente domestico.

Mica è vero, anche a casa la stabilità è importante...e cmq Stable = Testing non vuol dire assolutamente "stabile da essere usato nella maggior parte delle aziende", stabile da poter essere usato dalle aziende equivale a "rock solid = old stable"...programmi esenti da bug non esistono e mai esisteranno, però se un'azienda vuole migrare a libreoffice, si trova di fronte un programma definito stabile per l'uso aziendale, andando a fare i dovuti test viene fuori che il programma non è stabile manco per niente, scusami ma a libreoffice non ci passano neanche se gli spari...e ci penseranno sopra 10 volte prima di ritentare la migrazione.c'è anche un' altra cosa da considerare ...
se un programma tende a crashare (con perdita magari di dati o quantomeno del lavoro svolto fino a quel momento) compromette in varia misura la produttività, l' uptime o in generale il workflow aziendale, quindi che per un' azienda costituisca un fattore di rischio da evitare, è pacifico
ma un aspetto a cui spesso non si pensa è l' interoperabilità - ora, se già un singolo utente domestico (magari disposto a salvare i propri documenti in formati "alternativi" pur di poter impiegare applicazioni gratuite che comunque lo soddisfino, e non essere costretto a dotarsi di quelle standard di mercato, ma commerciali) può incorrere in problemi nello scambiare dati col resto del mondo, quando questo faccia in effetti uso dell' applicazione commerciale - per un' organizzazione in cui i documenti rappresentano un asset fondamentale (se non la vita stessa dell' organizzazione) e in cui è di svariati ordini di grandezza maggiore il numero dei passaggi e delle rielaborazioni che subiscono, è di vitale importanza che, per dire, la formattazione (ma anche le feature minori) del documento del documento siano fedelmente preservate - ovvero, che su quel tipo di documento sia garantita l' interoperabilità
fattore a cui spesso, specialmente se ragionando dal proprio limitato punto di vista di utenti domestici, non si pensa, ma che in effetti è più esteso e potenzialmente più grave di quello della stabilità (soprattutto nell' eventualità di perdite e incompatibilità a livello subdolo -non immediatamente evidenti - magari su grandi documenti...)
e nel caso ciò non avvenga, la garanzia (almeno sulla carta) che qualcuno se ne assumerà la responsabilità può fare la differenza - garanzia che può ampiamente giustificare i costi spesi per uno strumento piuttosto che un altro...
perchè, altro dettaglio spesso dimenticato, in un' organizzazione (aziendale, ma anche non) quel che conta davvero (e a cui si dà la priorità durante il BPR) è la struttura dell' azienda, dei processi in essa svolti ed eventualmente la ripartizione delle competenze dei singoli dipendenti - tutto quello che infici il workflow e di conseguenza efficienza ed efficacia dell' attività dell' azienda
in questo contesto il sw viene ultimo... importante in quanto strumentale al workflow aziendale, è però scelto sul mercato o sviluppato ad hoc in funzione di questo
pretendere come spesso si fa che un' organizzazione con un workflow consolidato e funzionante (magari comprendente applicazioni standard di mercato) lo modifichi solo per accomodarne di diverse e risparmiare sui costi di licenza delle prime (che peraltro spesso rappresentano una minima parte sul totale...) , è quantomeno irrealistico
Il problema non è la scelta, è come viene definito il programma, un programma che non è ancora realmente stabile non può essere definito "per le aziende"...gia io con le nomenclature che hai usato difficilmente userei una versione "testing", ma andrei su una più cauta "stable"...e sono un normale utente domestico.da quel lato, a ben vedere il problema è a un livello più basso, di mentalità diffusa...
una volta il versioning si affidava a una convenzione non ambigua insegnata nei corsi universitari e applicata dall' industria del software ...
ma questa si basa sull' assunto che il sw rilasciato come finale fosse intrinsecamente stabile "al meglio delle possibilità" (i programmatori sono sempre persone, e garantire l' assenza di bug è quasi impossibile -in realtà si fa, in certi ambiti e sotto certi, pesanti, limiti, ma è un discorso a parte) almeno privo di bug gravi e *noti (perchè sarebbe equivalente a vendere un prodotto con vizi all' origine, nel caso di una sw house espone a cause legali o quantomeno rischia di minare la reputazione) e che il codice che "è già tanto che giri" (alfa) e quello che "gira ma non è stabile, non gestisce tutti i possibili stati/input/errori ecc" (beta) sia da considerarsi ad uso interno ai fini del testing e fixing, e non destinato al pubblico
ora, è facile capire come la diffusione dell' open source, e sopratutto del movimento foss (che predica l' apertura del codice di modo che chiunque oltre allo sviluppatore originario possa mettervi le mani, e che si prefigge in modo nemmeno velato lo scopo di rendere gli utenti finali nuovi sviluppatori dedicati alla "causa") abbia modificato soprattutto quest' ultima assunzione - nonchè la percezione del ciclo di sviluppo, e di conseguenza del versioning, da parte del grande pubblico, o di una parte rilevante del pubblico
perchè adottare una convenzione in uso da parte dell' industria quando l' industria del sw è quello che ci si prefigge di sovvertire dal basso producendo codice per un pubblico da cui ci si aspettano contributi in termini di nuovo codice (sulla cui qualità non si potranno fare supposizioni a priori, ma non è un problema), quindi un pubblico che suppone composto da programmatori o nel peggiore dei casi da persone disposte a improvvisarsi tali?
perchè etichettare esplicitamente alfa o beta del codice che tanto, essendo svincolato da logiche commerciali di sviluppo a porte chiuse e product lifecycle (con annessi e connessi per quanto riguarda testing e supporto) e soggetto a continuo e "fluido" mutamento - viene distribuito al pubblico ad ogni iterazione (senza più distinzione tra release pubbliche e interne) e ad ogni iterazione d' altra parte conterrà per forza di cose bug noti e non noti (quelli noti fixati - forse - nella release successiva)?

perchè etichettare esplicitamente alfa o beta del codice che tanto, essendo svincolato da logiche commerciali di sviluppo a porte chiuse e product lifecycle (con annessi e connessi per quanto riguarda testing e supporto) e soggetto a continuo e "fluido" mutamento - viene distribuito al pubblico ad ogni iterazione (senza più distinzione tra release pubbliche e interne) e ad ogni iterazione d' altra parte conterrà per forza di cose bug noti e non noti (quelli noti fixati - forse - nella release successiva)?

Guarda, uso molti software gratuiti ed opensource che sono praticamente delle beta perenni, solo una volta all'anno una release viene rilasciata come completa e stabile...e cmq anche le beta sono stabili e non hanno grandissimi problemi.
Su una suite come libreoffice indubbiamente gestire i bug non è una cosa semplice, però invece di far uscire 4/5 versioni l'anno basta farne uscire 1 o 2 ben fatta/e, in pratica quello che faceva la sun prima e la oracle dopo, un paio di release l'anno abbastanza curate, voler accelerare lo sviluppo mi sta anche bene, ma fatto con coerenza...non vorrei che questa continua corsa all'innovazione rovini la suite invece di migliorarla.