stable vs new

users
#1

Hi :slight_smile:
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 :slight_smile:

#2

Hi :slight_smile:
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 :slight_smile:

#3

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

#4

Hi all!

  Thank you very much for the information !

Regards,

Jorge Rodríguez

#5

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

#6

Hi :slight_smile:
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 :slight_smile:

#7

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

#8

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

#9

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

#10

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

#11

Girvin,

#12

I'm with you on this. 3.6.7 works just fine for me.

Virgil

#13

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

#14

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