stable vs new

classic Classic list List threaded Threaded
15 messages Options
Tom Tom
Reply | Threaded
Open this post in threaded view
|

stable vs new

Hi :)
To put it as simply as possible ... 


A new branch starts off full of new stuff and some of that new stuff might cause unexpected problems on some machines.  There is no way around it.  It's not possible to test a new program on all possible combinations of hardware, OSes, programs and configurations.  During alpha and beta testing the new release is tested on as many systems as reasonably possible.  More people could help with that by running pre-release versions early on and reporting back any issues.  I try to but never seem to have the time and never really try out many different features anyway.  So, the

x.x.0

gets released and people start using it and reporting back some of the issues they find with it.  Some of those along with "known issues" and even obscure issues get fixed.  Instead of doing little updates every couple of days, like some programs do, these all get wrapped up into the next release, the

x.x.1
rinse and repeat to get the

x.x.2
and again for the

x.x.3
At this point most people say the branch is about as stable as possible so it starts being called stable branch.  However nothing new has been added for some time and some people have lots of exciting new ideas or have been working on something for years and finally got it working, others have been getting bored and started looking at other projects to get involved with to do more exciting things there.  So, while a lot of the devs stick with bug-fixes there are also a lot that move to an even newer branch.  So we have

x.x.4  = now called stable branch although earlier release in the same branch are not any more stable than they were before

x.y.0  = newer branch

then both branches develop alongside each other for a while giving us

x.x.5 = stable

x.y.1 = new(ish)

and then 

x.x.6 = very stable

x.y.2 = getting there

for the 1st time ever we ended up getting 

x.x.7 = very stable
x.y.3 = stable

x.z.0 = new branch

all at the same time.  Normally we don't bother with the .7 but the end of the 3.blah.blah was a bit momentous.  ( 3 has been around for years and years and moving to the 4 meant some significant changes.  I hadn't realised about the desktop-integration being pulled in and probably missed all the other changes too.  I was more concerned about java&accessibility issues but i think Stuart informed us that the newer java-access-bridge does now work with the newer LO releases.  So people don't need to stick with the 3.6.x branch to get their screen-readers working. )



Of course that is a bit simplistic.  The x.y.0 includes all the fixes that go into the x.x.4(ish) and maybe more as well.  However because of all the new stuff it might also suffer (or benefit from) regressions, some old problem might re-emerge, some new issues might arise.  "You can't make an omelette without breaking eggs".  Also the x.z.0 might introduce some "killer feature" that you just can't do without.  It's often better to start with a x.z.0 release because if you do find flaws and post bug-reports it catches the most devs attention and it's the point where the least number of users are posting bug-reports.  You are something like >25% more likely to get your pet-peeves dealt with at that time than at any other time or for any other release. 



So, the 3.6.7 is extremely stable.  The 4.0.3 and now the 4.0.4 'should be' plenty stable enough that hardly anyone has problems.  I gather the 4.0.3 was a bit of a let down but the 4.0.4 made up for that.  We 'should' initially try the 4.1.0 on our own machines but roll out the 4.0.4 (or wait for the 4.0.5) for machines that need to be stable.  Of course of the 4.1.0 has no problems in your environment then roll that one out.  It should be stable enough for almost every set-up even though stability is not it's main aim. 


Regards from

Tom :) 

--
To unsubscribe e-mail to: [hidden email]
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

V Stuart Foote V Stuart Foote
Reply | Threaded
Open this post in threaded view
|

RE: 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: [hidden email]
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

Tom Tom
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
>To: "[hidden email]" <[hidden email]>
>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: [hidden email]
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

Girvin Herr-2 Girvin Herr-2
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
>> To: "[hidden email]" <[hidden email]>
>> 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: [hidden email]
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

jorge-2 jorge-2
Reply | Threaded
Open this post in threaded view
|

RE: stable vs new

In reply to this post by V Stuart Foote
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: [hidden email]
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
V Stuart Foote V Stuart Foote
Reply | Threaded
Open this post in threaded view
|

Re: stable vs new

In reply to this post by Girvin Herr-2
Girvin,

Girvin R. Herr wrote
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.
Absolutely, there is nothing wrong with continuing to use the earlier releases.

Just be aware that the 3.6.x minor release will be designated EOL development status the 15th of this month.  Meaning, it is a final release (for the minor and 3.6 major branch) "No further patches will be accepted for the release" and no project effort to fix compatibility or security issues.  Support will continue in the mail list forum and the Ask site as well as Bugzilla issue tracking---but quality of that support will slack off as fewer users maintain a 3.6.x branch install.

LibOReleaseLifecycle.png

This graphic from the release plan presents a concise view of the project.   With work on the "master" branch extending into the future, each minor release branch is categorized as "release canidate", for "Early adopters", for "Recommended" use, for "Conservative" use.

With its EOL eminent, using 3.6.7 you would be well in the "Conservative" category--meaning simply that it is not the Project recommended category, which has shifted to the 4.0 major release--a 4.0.4 build.  Please note, that when released at the end of the month--the 4.0.5 build will also transition to a conservative category.

But as you say, what ever works best for your "productivity", we just want you and others to understand the project infrastructure and how best they can contribute.

Stuart
Tom Tom
Reply | Threaded
Open this post in threaded view
|

Most stable version right now Fw: [libreoffice-users] stable vs new

In reply to this post by Girvin Herr-2
Hi :)
I would only go with the 3.6.7 if you are currently on the 3.6.x branch and need to stay there or if you have need of staying with the accessibility java-bridge, older version for other programs. 


I think everyone else is better off with 4.0.4 and perhaps update in that branch as it steadily marches onwards.  

On the other hand i still have plenty of machines on 3.5.something and it's a free world so you can do as you please. 

Regards from

Tom :) 





----- Forwarded Message -----

>From: Girvin R. Herr <[hidden email]>
>To: Tom Davies <[hidden email]>
>Cc: V Stuart Foote <[hidden email]>; "[hidden email]" <[hidden email]>
>Sent: Sunday, 4 August 2013, 21:23
>Subject: 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 <[hidden email]>
>>> To: "[hidden email]" <[hidden email]>
>>> 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: [hidden email]
>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: [hidden email]
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

Cuyahoga Falls Cuyahoga Falls
Reply | Threaded
Open this post in threaded view
|

Re: stable vs new

In reply to this post by jorge-2
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: [hidden email]
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: [hidden email]
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: [hidden email]
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
Pedro Pedro
Reply | Threaded
Open this post in threaded view
|

Re: stable vs new

Hi Virgil

Virgil Arrington wrote
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.
Actually that is only true under Windows. Under Linux and Mac the default is parallel install.

In any case if you prefer to play it safe don't install any new versions under Windows. Just keep your x.x.7 build installed and use a portable version from winPenPack for testing. They are usually available a day or two after the official release by TDF at
http://sourceforge.net/projects/winpenpack/files/X-LibreOffice/releases/
and you can run as many as you like simultaneously.

Pedro
Girvin Herr-2 Girvin Herr-2
Reply | Threaded
Open this post in threaded view
|

Re: Most stable version right now Fw: [libreoffice-users] stable vs new

In reply to this post by Tom
I still abide by a statement attributed to Adam Osborne back in the 80s:
"He, who lives on the cutting edge of technology, gets sliced to bits."

Since the 3.6 series works fine for me, I will wait until the knife edge
dulls a bit before I make the leap to 4.1.
Girvin Herr


On 08/04/2013 02:08 PM, Tom Davies wrote:

> Hi :)
> I would only go with the 3.6.7 if you are currently on the 3.6.x branch and need to stay there or if you have need of staying with the accessibility java-bridge, older version for other programs.
>
>
> I think everyone else is better off with 4.0.4 and perhaps update in that branch as it steadily marches onwards.
>
> On the other hand i still have plenty of machines on 3.5.something and it's a free world so you can do as you please.
>
> Regards from
>
> Tom :)
>
>
>
>
>
> ----- Forwarded Message -----
>> From: Girvin R. Herr <[hidden email]>
>> To: Tom Davies <[hidden email]>
>> Cc: V Stuart Foote <[hidden email]>; "[hidden email]" <[hidden email]>
>> Sent: Sunday, 4 August 2013, 21:23
>> Subject: 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 <[hidden email]>
>>>> To: "[hidden email]" <[hidden email]>
>>>> 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: [hidden email]
>> 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: [hidden email]
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

Girvin Herr-2 Girvin Herr-2
Reply | Threaded
Open this post in threaded view
|

Re: stable vs new

In reply to this post by V Stuart Foote
Stuart,
Thanks for taking the time to explain this.
You are correct, I tend to be in the late "recommended" to early
"conservative" category.
I also believe in "if it ain't broke, don't fix it." and LO 3.6 is
currently working fine for what I expect of it.

I also have another rule that unless there is a really, really
compelling reason to, I never install software with a version ending in
zero, like 4.0 or 4.1.0.  Therefore, I am holding out for the 4.1.3+
release.

Thanks again.
Girvin


On 08/04/2013 02:03 PM, V Stuart Foote wrote:

> Girvin,
>
>
> Girvin R. Herr wrote
>> 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.
> Absolutely, there is nothing wrong with continuing to use the earlier
> releases.
>
> Just be aware that the 3.6.x minor release will be designated EOL
> development status the 15th of this month.  Meaning, it is a final release
> (for the minor and 3.6 major branch) "No further patches will be accepted
> for the release" and no project effort to fix compatibility or security
> issues.  Support will continue in the mail list forum and the Ask site as
> well as Bugzilla issue tracking---but quality of that support will slack off
> as fewer users maintain a 3.6.x branch install.
>
> LibOReleaseLifecycle.png
> <https://wiki.documentfoundation.org/images/2/2c/LibOReleaseLifecycle.png>
>
> This graphic from the release plan presents a concise view of the project.
> With work on the "master" branch extending into the future, each minor
> release branch is categorized as "release canidate", for "Early adopters",
> for "Recommended" use, for "Conservative" use.
>
> With its EOL eminent, using 3.6.7 you would be well in the "Conservative"
> category--meaning simply that it is not the Project recommended category,
> which has shifted to the 4.0 major release--a 4.0.4 build.  Please note,
> that when released at the end of the month--the 4.0.5 build will also
> transition to a conservative category.
>
> But as you say, what ever works best for your "productivity", we just want
> you and others to understand the project infrastructure and how best they
> can contribute.
>
> Stuart
>
>
>
>
> --
> View this message in context: http://nabble.documentfoundation.org/stable-vs-new-tp4068750p4068822.html
> Sent from the Users mailing list archive at Nabble.com.
>


--
To unsubscribe e-mail to: [hidden email]
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

V Stuart Foote V Stuart Foote
Reply | Threaded
Open this post in threaded view
|

Re: stable vs new

Girvin,
________________________________________
From: Girvin R. Herr [[hidden email]]
Sent: Tuesday, August 06, 2013 1:20 PM
...
I also have another rule that unless there is a really, really
compelling reason to, I never install software with a version ending in
zero, like 4.0 or 4.1.0.  Therefore, I am holding out for the 4.1.3+
release.

Exactly, and here is where this model for timed release comes in. As an aid in planning technology issues, you can expect a 4.1.3 release to be ready for you about the 3rd of November, give or take a few days.   You've got time to prepare, and maybe take the 4.1.x branch out for a spin on the side as a parallel or /Administrative install...

Stuart

--
To unsubscribe e-mail to: [hidden email]
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

Cuyahoga Falls Cuyahoga Falls
Reply | Threaded
Open this post in threaded view
|

Re: Most stable version right now Fw: [libreoffice-users] stable vs new

In reply to this post by Girvin Herr-2
On 08/06/2013 02:07 PM, Girvin R. Herr wrote:
> I still abide by a statement attributed to Adam Osborne back in the
> 80s: "He, who lives on the cutting edge of technology, gets sliced to
> bits."
>
> Since the 3.6 series works fine for me, I will wait until the knife
> edge dulls a bit before I make the leap to 4.1.
> Girvin Herr
>
I'm with you on this. 3.6.7 works just fine for me.

Virgil

--
To unsubscribe e-mail to: [hidden email]
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

Screwbottle Screwbottle
Reply | Threaded
Open this post in threaded view
|

Re: Most stable version right now Fw: [libreoffice-users] stable vs new

Heh! Heh! nice one Girvin. I will have to sensor my saying my late
military father used to drum into me. Similiar to Adam Osbourne and
applied in a military vein, and I take no credit from it, or know who
the original author is etc.

"The pain and frustration of living on the cutting edge, is like being
an ant sliding down a 20 foot razor blade using your (part of the male
anatomy, rhymes with many golf balls) as brakes"

Regards

Andrew Brown

On 06/08/2013 09:05 PM, Virgil Arrington wrote:

> On 08/06/2013 02:07 PM, Girvin R. Herr wrote:
>> I still abide by a statement attributed to Adam Osborne back in the
>> 80s: "He, who lives on the cutting edge of technology, gets sliced to
>> bits."
>>
>> Since the 3.6 series works fine for me, I will wait until the knife
>> edge dulls a bit before I make the leap to 4.1.
>> Girvin Herr
>>
> I'm with you on this. 3.6.7 works just fine for me.
>
> Virgil
>


--
To unsubscribe e-mail to: [hidden email]
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

Girvin Herr-2 Girvin Herr-2
Reply | Threaded
Open this post in threaded view
|

Re: Most stable version right now Fw: [libreoffice-users] stable vs new

Andrew,
Ouch!  Just thinking about that one makes me wince!
Take care.
Girvin


On 08/06/2013 12:36 PM, Andrew Brown wrote:

> Heh! Heh! nice one Girvin. I will have to sensor my saying my late
> military father used to drum into me. Similiar to Adam Osbourne and
> applied in a military vein, and I take no credit from it, or know who
> the original author is etc.
>
> "The pain and frustration of living on the cutting edge, is like being
> an ant sliding down a 20 foot razor blade using your (part of the male
> anatomy, rhymes with many golf balls) as brakes"
>
> Regards
>
> Andrew Brown
>
> On 06/08/2013 09:05 PM, Virgil Arrington wrote:
>> On 08/06/2013 02:07 PM, Girvin R. Herr wrote:
>>> I still abide by a statement attributed to Adam Osborne back in the
>>> 80s: "He, who lives on the cutting edge of technology, gets sliced
>>> to bits."
>>>
>>> Since the 3.6 series works fine for me, I will wait until the knife
>>> edge dulls a bit before I make the leap to 4.1.
>>> Girvin Herr
>>>
>> I'm with you on this. 3.6.7 works just fine for me.
>>
>> Virgil
>>
>
>


--
To unsubscribe e-mail to: [hidden email]
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