RE: [libreoffice-users] stable vs new
Folks, In opening this thread ( Nabble http://nabble.documentfoundation.org/stable-vs-new-tp4068750.html ) Tom is correct in a practical sense. Stability is an inherent component of a mature product. And testing during the development cycles by more potential user willing to invest a little time in QA is essential to the health of the project. But a key aspect Tom omits is that LibreOffice development and release stages are tightly timed--and by proxy so is its support. Nor does he mention that the project has stayed on schedule since inception--synchronizing to a six month minor release cycle implemented in a broader ecosystem of Free and Open Source Software. The Release Plan for LibreOffice publishes the release schedule, current status and a historical record of the project, worth a read: https://wiki.documentfoundation.org/Release_Plan Keeping to the time based release plan means that the delay between initial release on a minor version and the next minor version release is just six months. And that the delay between the x.x.0 release and each bug fix release has been and will continue to be just one month. So, while I don't completely agree Toms' assessment of how far along each bug fix takes things--it is just not the way the user feedback, QA,and development work proceeds--but it is not unreasonable practical advise. Support has kept to the same cycle--for the most part--user documentation (static HTML or wiki based, and published) can always use more active contributors and lags a bit as a result. This is not just development churn, there is solid User eXperience, QA and development work at every tick of the release cycle. And as a minor release nears end of its development life it gets less and less development attenetion--QA and development resources long since shifted to new development and bug fixes. Enhancements and bug fixes become more and more costly to push backward with each tick in development cycle--so less likely to occur. In a sense that also is stability, or maybe stagnation. The project is on sound footings as a time based release, that is not going to change so no sense in debating it here. Rather, if you have specific questions or comments about its implementation or how best to make use of software from time based release manged project that would be a worthwhile discussion. Stuart a LibreOffice QA volunteer, focusing on accessibility issues. p.s. For use Accessibility and Assistive Technology tools the use of a Java 7, Java Runtime Environment and the Java Access Bridge v2.0.3 was not ported backward to the 3.6.x branch. It was included in the 4.1.0 release, and has been patched for the upcoming 4.0.5 release. Users of 3.6.x must continue to use a Java 6 JRE (e.g. 1.6u45) and manual install of Java Access Bridge v2.0.2. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] stable vs new
Hi :) Yes, i was trying to keep it simple and practical by avoiding side issues or detail. Even so my post turned out to be a lot longer than planned! For some projects stability = stagnation ie that the 3.0.0 could be considered stable because pretty much all the bugs are known issues and mostly written-up somewhere. That has never been considered good enough in LO. The earlier releases in a branch are not considered more stable after the branch reaches .3 or .4. It's only the .3 or .4 and onwards that are considered more stable. Time-based releases vs release when ready. Whichever methodology is used it's only after initial proper release that the thing gets used on the mad set-ups out in the real world that most problems surface and get fixed. With MS products many corporates wouldn't consider installing before Service Pack 1 got released, which means it's only after SP 1 that many problems come to light! So, i agree with Stuart and most of the rest of the project on this issue. I'm sure the arguments about which is best will continue for another 7 years in most projects (and possibly longer). We all get to play ginea pig but we would with proprietary software too. The difference is that if a problem we reported does get fixed we get the fix for free along with all the updates that we didn't help with. There is no paying for upgrades or being pushed into buying a different bundle by some salesman. Regards from Tom :) From: V Stuart Foote vstuart.fo...@utsa.edu To: users@global.libreoffice.org users@global.libreoffice.org Sent: Sunday, 4 August 2013, 16:58 Subject: RE: [libreoffice-users] stable vs new Folks, In opening this thread ( Nabble http://nabble.documentfoundation.org/stable-vs-new-tp4068750.html ) Tom is correct in a practical sense. Stability is an inherent component of a mature product. And testing during the development cycles by more potential user willing to invest a little time in QA is essential to the health of the project. But a key aspect Tom omits is that LibreOffice development and release stages are tightly timed--and by proxy so is its support. Nor does he mention that the project has stayed on schedule since inception--synchronizing to a six month minor release cycle implemented in a broader ecosystem of Free and Open Source Software. The Release Plan for LibreOffice publishes the release schedule, current status and a historical record of the project, worth a read: https://wiki.documentfoundation.org/Release_Plan Keeping to the time based release plan means that the delay between initial release on a minor version and the next minor version release is just six months. And that the delay between the x.x.0 release and each bug fix release has been and will continue to be just one month. So, while I don't completely agree Toms' assessment of how far along each bug fix takes things--it is just not the way the user feedback, QA,and development work proceeds--but it is not unreasonable practical advise. Support has kept to the same cycle--for the most part--user documentation (static HTML or wiki based, and published) can always use more active contributors and lags a bit as a result. This is not just development churn, there is solid User eXperience, QA and development work at every tick of the release cycle. And as a minor release nears end of its development life it gets less and less development attention--QA and development resources long since shifted to new development and bug fixes. Enhancements and bug fixes become more and more costly to push backward with each tick in development cycle--so less likely to occur. In a sense that also is stability, or maybe stagnation. The project is on sound footings as a time based release, that is not going to change so no sense in debating it here. Rather, if you have specific questions or comments about its implementation or how best to make use of software from time based release managed project that would be a worthwhile discussion. Stuart a LibreOffice QA volunteer, focusing on accessibility issues. p.s. For use Accessibility and Assistive Technology tools the use of a Java 7, Java Runtime Environment and the Java Access Bridge v2.0.3 was not ported backward to the 3.6.x branch. It was included in the 4.1.0 release, and has been patched for the upcoming 4.0.5 release. Users of 3.6.x must continue to use a Java 6 JRE (e.g. 1.6u45) and manual install of Java Access Bridge v2.0.2. -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] stable vs new
Tom, To me: stability = productivity But I am just a lowly user. Nice description! I saved it for future reference. Now I know why I keep getting 3.x update notices when 4.x has been released some time ago. That surprised, but pleased, me. As a result of your description, I will have to repackage and install 3.6.7 after my monthly backup today. Girvin Herr On 08/04/2013 10:35 AM, Tom Davies wrote: Hi :) Yes, i was trying to keep it simple and practical by avoiding side issues or detail. Even so my post turned out to be a lot longer than planned! For some projects stability = stagnation ie that the 3.0.0 could be considered stable because pretty much all the bugs are known issues and mostly written-up somewhere. That has never been considered good enough in LO. The earlier releases in a branch are not considered more stable after the branch reaches .3 or .4. It's only the .3 or .4 and onwards that are considered more stable. Time-based releases vs release when ready. Whichever methodology is used it's only after initial proper release that the thing gets used on the mad set-ups out in the real world that most problems surface and get fixed. With MS products many corporates wouldn't consider installing before Service Pack 1 got released, which means it's only after SP 1 that many problems come to light! So, i agree with Stuart and most of the rest of the project on this issue. I'm sure the arguments about which is best will continue for another 7 years in most projects (and possibly longer). We all get to play ginea pig but we would with proprietary software too. The difference is that if a problem we reported does get fixed we get the fix for free along with all the updates that we didn't help with. There is no paying for upgrades or being pushed into buying a different bundle by some salesman. Regards from Tom :) From: V Stuart Foote vstuart.fo...@utsa.edu To: users@global.libreoffice.org users@global.libreoffice.org Sent: Sunday, 4 August 2013, 16:58 Subject: RE: [libreoffice-users] stable vs new Folks, In opening this thread ( Nabble http://nabble.documentfoundation.org/stable-vs-new-tp4068750.html ) Tom is correct in a practical sense. Stability is an inherent component of a mature product. And testing during the development cycles by more potential user willing to invest a little time in QA is essential to the health of the project. But a key aspect Tom omits is that LibreOffice development and release stages are tightly timed--and by proxy so is its support. Nor does he mention that the project has stayed on schedule since inception--synchronizing to a six month minor release cycle implemented in a broader ecosystem of Free and Open Source Software. The Release Plan for LibreOffice publishes the release schedule, current status and a historical record of the project, worth a read: https://wiki.documentfoundation.org/Release_Plan Keeping to the time based release plan means that the delay between initial release on a minor version and the next minor version release is just six months. And that the delay between the x.x.0 release and each bug fix release has been and will continue to be just one month. So, while I don't completely agree Toms' assessment of how far along each bug fix takes things--it is just not the way the user feedback, QA,and development work proceeds--but it is not unreasonable practical advise. Support has kept to the same cycle--for the most part--user documentation (static HTML or wiki based, and published) can always use more active contributors and lags a bit as a result. This is not just development churn, there is solid User eXperience, QA and development work at every tick of the release cycle. And as a minor release nears end of its development life it gets less and less development attention--QA and development resources long since shifted to new development and bug fixes. Enhancements and bug fixes become more and more costly to push backward with each tick in development cycle--so less likely to occur. In a sense that also is stability, or maybe stagnation. The project is on sound footings as a time based release, that is not going to change so no sense in debating it here. Rather, if you have specific questions or comments about its implementation or how best to make use of software from time based release managed project that would be a worthwhile discussion. Stuart a LibreOffice QA volunteer, focusing on accessibility issues. p.s. For use Accessibility and Assistive Technology tools the use of a Java 7, Java Runtime Environment and the Java Access Bridge v2.0.3 was not ported backward to the 3.6.x branch. It was included in the 4.1.0 release, and has been patched for the upcoming 4.0.5 release. Users of 3.6.x must continue to use a Java 6 JRE (e.g. 1.6u45) and manual install of Java Access Bridge v2.0.2. -- To unsubscribe e
RE: [libreoffice-users] stable vs new
Hi all! Thank you very much for the information ! Regards, Jorge Rodríguez El dom, 04-08-2013 a las 15:58 +, V Stuart Foote escribió: Folks, In opening this thread ( Nabble http://nabble.documentfoundation.org/stable-vs-new-tp4068750.html ) Tom is correct in a practical sense. Stability is an inherent component of a mature product. And testing during the development cycles by more potential user willing to invest a little time in QA is essential to the health of the project. But a key aspect Tom omits is that LibreOffice development and release stages are tightly timed--and by proxy so is its support. Nor does he mention that the project has stayed on schedule since inception--synchronizing to a six month minor release cycle implemented in a broader ecosystem of Free and Open Source Software. The Release Plan for LibreOffice publishes the release schedule, current status and a historical record of the project, worth a read: https://wiki.documentfoundation.org/Release_Plan Keeping to the time based release plan means that the delay between initial release on a minor version and the next minor version release is just six months. And that the delay between the x.x.0 release and each bug fix release has been and will continue to be just one month. So, while I don't completely agree Toms' assessment of how far along each bug fix takes things--it is just not the way the user feedback, QA,and development work proceeds--but it is not unreasonable practical advise. Support has kept to the same cycle--for the most part--user documentation (static HTML or wiki based, and published) can always use more active contributors and lags a bit as a result. This is not just development churn, there is solid User eXperience, QA and development work at every tick of the release cycle. And as a minor release nears end of its development life it gets less and less development attenetion--QA and development resources long since shifted to new development and bug fixes. Enhancements and bug fixes become more and more costly to push backward with each tick in development cycle--so less likely to occur. In a sense that also is stability, or maybe stagnation. The project is on sound footings as a time based release, that is not going to change so no sense in debating it here. Rather, if you have specific questions or comments about its implementation or how best to make use of software from time based release manged project that would be a worthwhile discussion. Stuart a LibreOffice QA volunteer, focusing on accessibility issues. p.s. For use Accessibility and Assistive Technology tools the use of a Java 7, Java Runtime Environment and the Java Access Bridge v2.0.3 was not ported backward to the 3.6.x branch. It was included in the 4.1.0 release, and has been patched for the upcoming 4.0.5 release. Users of 3.6.x must continue to use a Java 6 JRE (e.g. 1.6u45) and manual install of Java Access Bridge v2.0.2. -- Atentamente, Jorge Rodríguez -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] stable vs new
Yes, thank you for the information. I now get it, and it does make sense. Now, if we can just get a new branch of LO (x.y.0) to stop overwriting an older branch (x.x.7) by default, I would a most happy man. Virgil -Original Message- From: jorge Sent: Sunday, August 04, 2013 4:41 PM To: V Stuart Foote Cc: users@global.libreoffice.org Subject: RE: [libreoffice-users] stable vs new Hi all! Thank you very much for the information ! Regards, Jorge Rodríguez El dom, 04-08-2013 a las 15:58 +, V Stuart Foote escribió: Folks, In opening this thread ( Nabble http://nabble.documentfoundation.org/stable-vs-new-tp4068750.html ) Tom is correct in a practical sense. Stability is an inherent component of a mature product. And testing during the development cycles by more potential user willing to invest a little time in QA is essential to the health of the project. But a key aspect Tom omits is that LibreOffice development and release stages are tightly timed--and by proxy so is its support. Nor does he mention that the project has stayed on schedule since inception--synchronizing to a six month minor release cycle implemented in a broader ecosystem of Free and Open Source Software. The Release Plan for LibreOffice publishes the release schedule, current status and a historical record of the project, worth a read: https://wiki.documentfoundation.org/Release_Plan Keeping to the time based release plan means that the delay between initial release on a minor version and the next minor version release is just six months. And that the delay between the x.x.0 release and each bug fix release has been and will continue to be just one month. So, while I don't completely agree Toms' assessment of how far along each bug fix takes things--it is just not the way the user feedback, QA,and development work proceeds--but it is not unreasonable practical advise. Support has kept to the same cycle--for the most part--user documentation (static HTML or wiki based, and published) can always use more active contributors and lags a bit as a result. This is not just development churn, there is solid User eXperience, QA and development work at every tick of the release cycle. And as a minor release nears end of its development life it gets less and less development attenetion--QA and development resources long since shifted to new development and bug fixes. Enhancements and bug fixes become more and more costly to push backward with each tick in development cycle--so less likely to occur. In a sense that also is stability, or maybe stagnation. The project is on sound footings as a time based release, that is not going to change so no sense in debating it here. Rather, if you have specific questions or comments about its implementation or how best to make use of software from time based release manged project that would be a worthwhile discussion. Stuart a LibreOffice QA volunteer, focusing on accessibility issues. p.s. For use Accessibility and Assistive Technology tools the use of a Java 7, Java Runtime Environment and the Java Access Bridge v2.0.3 was not ported backward to the 3.6.x branch. It was included in the 4.1.0 release, and has been patched for the upcoming 4.0.5 release. Users of 3.6.x must continue to use a Java 6 JRE (e.g. 1.6u45) and manual install of Java Access Bridge v2.0.2. -- Atentamente, Jorge Rodríguez -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
