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: [email protected]
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 +0000, 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: [email protected]
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: [email protected]
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
