LibreOffice Still?

Or go the Debian way...

4.3 would be the 'Testing' branch...

4.2.x would be the Stable branch...

Which, by definition, makes it "more stable".

Hence why plenty of open source software uses the terminology of a
stable branch vs. "testing", "bleeding edge", "development", etc.

Some sites say that the bleeding edge is *not* stable, so be warned,
others say that the development branch is very stable, with more
features, but does have the potential for more bugs, and leave the
choice up to the end user.

Why don't we do the same? This is well established tradition that many
will be used to and understand, and those that aren't familiar with
it can be guided in their choice by a simple description.

In fact, the current download page has no description whatsoever,
making it extremely unfriendly when it also uses unfamiliar
terminology. Simply adding a description, and *not* making a ".0"
release the default choice, would go a long way towards making this
whole argument a little less relevant, although using standard
terminology as well is still the best way to go, by miles.

Really? So a software "being around" gets patches through the Holy Spirit? LTS versions are never declared LTS months after they are released. One version (one over two, in the case of Canonical) is agreed and announced as LTS, and receives a specific treatment resulting from a specific contract for a specific (longer) period of time. LTS implies the existence of a business and a support machinery, not the virtue of time.

best,

Charles.

Hi,

So, you do go through stages. You just misnomered them.

Why not just use that?

Stages:
Alpha
Beta
Release Candidate
Final Release Candidate (LO v4.3.0)
Stable (LO v4.2.6)

Please read this page to know more about our development process
https://wiki.documentfoundation.org/ReleasePlan
and this to know more about the naming of our versions
https://wiki.documentfoundation.org/ReleasePlan#Version_scheme

May be you'll understand that both are fully tested and stable.
But LibreOffice is a software that is used in very different
environments that we can't reproduce in our own. That's why, the time
being, advanced users are helping us to reduce the number of bugs and
regressions, that doesn't make the version unstable however.

Kind regards
Sophie

> Clearly it is not so easy for new people to figure it out otherwise
> we wouldn't keep on having to answer this same question from so
> many new users.

So you answer them and they will know, this is how support works.

This works for support *after* they have gotten the software, this
should *never* be the case for people who want to download the
software, that choice should *always* be pretty obvious.

If I go to a page to download some software I want, and can't figure
out which version I should use, or at least have some sort of idea
about the choice being made, I consider just giving up on the software.
I'm sure most people are the same.

Honestly that's not what is perceived in terms of stats however it is true we could do with clearer explanations(and these should be positive, not in the form of "this branch is really less stable than the other" - that is not what is wanted here...

Yes, but you keep thinking on the same model: stable vs unstable when
both are stable :slight_smile: change your mind by thinking older in time = more
bugfixes, newer in time = more features but more bugs.

But you're getting the very definition of stable wrong:

more bugs = less stable

So this really *is* a debate about stable vs unstable. That's not to say
that the younger product is *unstable*, but it does mean that the older
product is *more stable*.

Which, indeed, led us to change the term "stable" into something else. Stable is a state, not a definitive truth. Indeed, the older branch is "more stable", let's call it "more mature". In fact, the the term mature was seriously considered but as I explained elsewhere, there was a bit of a pickle with respect to the use of the term "mature" on the Internet...

best,

Charles.

Hi :slight_smile:
Ok, so that sounds like the 4th or 6th "cycle" of a branch has
reduced the bugs and regressions = i think most people would call
that making it more stable wouldn't they?

By definition, yes.

"Stable" is hard to define, although on it's own it does lean towards
meaning "no bugs that crash the system in any way", but "More Stable"
for sure means "less bugs of any sort".

Then the point about recent releases having had less usage seems to be
saying that it is not quite so stable.

Again, yes. Part of the problem is some people commenting seem to think
that if one branch is "stable", the other must be "unstable". This is
not true. Normal practice in the open source world is to call the most
stable branch "stable", and the less stable branch (note, less stable,
by definition, but not necessarily unstable) something like
"development", or even "latest". Heck, even "Stable" and "Fresh" would
be waaaay better than what we have now.

So i think we still need to try to think of a really short name for
each branch that describes what it's advantage is over the other
branch.

"Stable" for the more mature branch is a no brainer.

The other branch can be something like "Development" or even
still "Fresh".

Part of the problem lies, in my opinion, in not having a relevant
description of the terms on the download page. Users should never
simply be shown such terms and assumed to know what they mean. The
download page should *always* give a brief description of what the
terms mean, and there should be an easily visible link to a description
of the two, explaining to new users why they may want one over the
other.

Hi,
> So, you do go through stages. You just misnomered them.
>
> Why not just use that?
>
> Stages:
> Alpha
> Beta
> Release Candidate
> Final Release Candidate (LO v4.3.0)
> Stable (LO v4.2.6)

Please read this page to know more about our development process
https://wiki.documentfoundation.org/ReleasePlan
and this to know more about the naming of our versions
https://wiki.documentfoundation.org/ReleasePlan#Version_scheme

May be you'll understand that both are fully tested and stable.

But one is "more stable".

But LibreOffice is a software that is used in very different
environments that we can't reproduce in our own. That's why, the time
being, advanced users are helping us to reduce the number of bugs and
regressions, that doesn't make the version unstable however.

No, but it does make it "less stable".

These are important terms that are widely used in open source software.
Why does LO feel the need to be different? It can only lead to
confusion, especially with a lack of explanation around the terms on
the download page.

And I'd go so far as to say that the chosen alternatives are poor.
"Fresh" might be fine, but "Still" makes one think that it has reached
end of life, and won't be updated anymore.

>
>> > Clearly it is not so easy for new people to figure it out
>> > otherwise we wouldn't keep on having to answer this same
>> > question from so many new users.
>>
>> So you answer them and they will know, this is how support works.
>
> This works for support *after* they have gotten the software, this
> should *never* be the case for people who want to download the
> software, that choice should *always* be pretty obvious.
>
> If I go to a page to download some software I want, and can't figure
> out which version I should use, or at least have some sort of idea
> about the choice being made, I consider just giving up on the
> software. I'm sure most people are the same.

Honestly that's not what is perceived in terms of stats however it is
true we could do with clearer explanations(and these should be
positive, not in the form of "this branch is really less stable than
the other" - that is not what is wanted here...

I'd be interested to know what stats you have. I can't think of any
stats that would indicate this. Either people go there, and are confused
and go away without downloading anything, or they do download
something, and you have a new user. But so many people must also go to
the page and not download anything for other reasons (like myself, who
just went there earlier to confirm the wording on the page, or when I
go there just to check what the latest version is), so I'm not sure how
you could have any stats that indicate how many people are leaving due
to being unsure of the terminology.

> So this really *is* a debate about stable vs unstable. That's not
> to say
> that the younger product is *unstable*, but it does mean that the
> older product is *more stable*.

Which, indeed, led us to change the term "stable" into something
else.

And that was, IMHO, a bad choice. The term is widely used and
understood on the internet, and changing it, even if you had chosen a
better word, would still have been not what people know and understand,
leaving open the potential for confusion.

Stable is a state, not a definitive truth.

But it is still a good word for the older branch, as explained above.

And we come back to the beginning of the discussion, if you have better
names, the marketing team will be happy to discuss them :slight_smile:
Kind regards
Sophie

Sure, please pass on to the team:

"Stable"
"Development" (or "Current", or "Latest")

And please add a note about putting the descriptions on the download
page, it's even more important than the names chosen.

Oh, and also don't make a ".0" release the default.

Paul : did you intend to post this off list?

No, sorry, my bad for not checking the address. I just clicked "reply".
For most messages that goes to the list, I don't know why some people
seem to have it that their messages are set to reply off-list.

>Sorry, Charles, but I have to respectfully disagree:
>
>
>
>> >
>> >> LTS will never, however magically produce a "better quality
>> >> release"
>> >
>> > No, not magically, but by the very nature of it being around for
>> > longer it will, in the end, result in a more stable product.
>>
>>
>> Really? So a software "being around" gets patches through the Holy
>> Spirit?
>
>No, it gets patches the same way a ".6" release of a software gets
>more patches than a ".0" release.

That is your definition of an LTS. Not a bad one but it does not
change the definition much...

It is merely the common definition.

>The idea of a version being around for
>longer having more patches in it is well understood, and in fact has
>been something you have commented on regarding the benefit of the
>"Still" branch.
>
>LTS versions don't *start off* more stable, they only become more
>stable.

I agree.
>
>
>> LTS implies the existence of a business and a support
>> machinery, not the virtue of time.
>
>No, it doesn't. It may be the case for Canonical that the LTS
>version has more support machinery, but the concept of LTS is just
>that it will be supported for a guaranteed amount of time, and not
>retired early, such that adopters can be sure that for a specific
>duration they will not have to upgrade to get support and patches.

So developers will obviously have an incentive to develop a LTS for
free... not really seen this working well before honestly. And I have
been working in linux distros for some time.

They will have the same incentive that they do for any release. Why
would they decide not to work on it just because they are not being
paid? They're not being paid for any of their other work anyway.

Hello Paul,

Paul : did you intend to post this off list?

No, sorry, my bad for not checking the address. I just clicked "reply".
For most messages that goes to the list, I don't know why some people
seem to have it that their messages are set to reply off-list.

>Sorry, Charles, but I have to respectfully disagree:
>
>
>
>> >
>> >> LTS will never, however magically produce a "better quality
>> >> release"
>> >
>> > No, not magically, but by the very nature of it being around for
>> > longer it will, in the end, result in a more stable product.
>>
>>
>> Really? So a software "being around" gets patches through the Holy

>> Spirit?
>
>No, it gets patches the same way a ".6" release of a software gets
>more patches than a ".0" release.

That is your definition of an LTS. Not a bad one but it does not
change the definition much...

It is merely the common definition.

Where can I find this common definition? To me it is a possible one but not the exclusive one . Anyway: it does not overly matter in our case.

>The idea of a version being around for
>longer having more patches in it is well understood, and in fact has
>been something you have commented on regarding the benefit of the
>"Still" branch.
>
>LTS versions don't *start off* more stable, they only become more
>stable.

I agree.
>
>
>> LTS implies the existence of a business and a support
>> machinery, not the virtue of time.
>
>No, it doesn't. It may be the case for Canonical that the LTS
>version has more support machinery, but the concept of LTS is just
>that it will be supported for a guaranteed amount of time, and not
>retired early, such that adopters can be sure that for a specific
>duration they will not have to upgrade to get support and patches.

So developers will obviously have an incentive to develop a LTS for
free... not really seen this working well before honestly. And I have
been working in linux distros for some time.

They will have the same incentive that they do for any release. Why
would they decide not to work on it just because they are not being
paid? They're not being paid for any of their other work anyway.

Ah. You seem to ignore 1) the itch to scratch 2) money as an incentive. To think that they are not paid for any of their work is both factually wrong and dangerous. At least within the LibreOffice project and many others as well developers are paid directly or indirectly for their work on libreoffice.

Best,

Charles.

Hi :slight_smile:
Yeh, i have always thought that giving the newest users the least stable
version is a bad idea.

At the moment it is only once you are familiar with LibreOffice and become
able to cope with problems more easily that you are able to get the least
buggy version!

One of the problems with the 2 branches is that what we really have is more
like;

1. Stable branch
2. VERY stable branch

It's not like one of the branches is ever unstable, development or anything
like that. It's just that one has become even more stable. So i can see
why people have trouble coming up with a name. I really like Tim's (at
Kracked Press) idea. That way really makes a lot of sense to me.

I agree that having some sort of BRIEF explanation on the page might help
people make up their minds which to choose. The problem would be that a
lot of the explanations in this thread are more like politicians excuses
and end up obscuring the advantages of each instead of clarifying them. I
can easily imagine both having the same description.

Regards from
Tom :slight_smile:

Hi Tom,

If we do not find the bugs in the fresh version, they won't be resolved until the rename to Stable/Still. If less use Fresh, the quality of the next stable will be lower.... Does this help?

Liebe Grüße, / Yours,
Florian Reisinger

Tom Davies wrote:

I am beginning to like the sound of "mature branch" and "young branch".

http://en.wikipedia.org/wiki/Mature_technology : "A mature technology is a technology that has been in use for long enough that most of its initial faults and inherent problems have been removed or reduced by further development." Seems to fit the bill nicely.

Of
course a google search for mature, or young, might bring up some bad sites
that we wouldn't want to be associated with. It's annoying because
otherwise that might be a really good way of describing the difference
between the 2 branches.

Someone looking for info on the "mature" version of LibreOffice isn't going to search simply for "mature"; they're going to include LibreOffice in the search terms. Currently, a quick search on Google for "LibreOffice mature download" gives at least the first 3 pages of results all relating to LibreOffice.

I don't see "mature" as being any worse than "fresh" in terms of other connotations it might have (I'm in the UK; maybe it's different in other parts of the world...)

So i think we still need to try to think of a really short name for each
branch that describes what it's advantage is over the other branch.

"Fresh" and "Mature" seem fine to me. Alternatively, perhaps "long term support" for the older branch, although I'm not sure that's really accurate since the life cycle of the stable/still/mature/LTS/whatever branch is no longer than any other. As someone else mentioned, whatever terms are used need to be explained in a few words on the downloads page.

To me, "Still" sounds like that branch is stagnant, no longer developed, abandoned... (more apt for the 4.0 branch I'm still using ;o)

Mark.

Hello Paul,

>
>
>
>
>> Paul : did you intend to post this off list?
>
>No, sorry, my bad for not checking the address. I just clicked
>"reply". For most messages that goes to the list, I don't know why
>some people seem to have it that their messages are set to reply
>off-list.
>
>> >Sorry, Charles, but I have to respectfully disagree:
>> >
>> >
>> >
>> >> >
>> >> >> LTS will never, however magically produce a "better quality
>> >> >> release"
>> >> >
>> >> > No, not magically, but by the very nature of it being around
>> >> > for longer it will, in the end, result in a more stable
>> >> > product.
>> >>
>> >>
>> >> Really? So a software "being around" gets patches through the
>> >> Holy
>
>> >> Spirit?
>> >
>> >No, it gets patches the same way a ".6" release of a software gets
>> >more patches than a ".0" release.
>>
>> That is your definition of an LTS. Not a bad one but it does not
>> change the definition much...
>
>It is merely the common definition.

Where can I find this common definition? To me it is a possible one
but not the exclusive one . Anyway: it does not overly matter in our
case.

http://en.wikipedia.org/wiki/Long-term_support

"Long-term support (LTS) is term used to describe special versions or
editions of software designed to be supported for a longer than normal
period."

>
>>
>> >The idea of a version being around for
>> >longer having more patches in it is well understood, and in fact
>> >has been something you have commented on regarding the benefit of
>> >the "Still" branch.
>> >
>> >LTS versions don't *start off* more stable, they only become more
>> >stable.
>>
>> I agree.
>> >
>> >
>> >> LTS implies the existence of a business and a support
>> >> machinery, not the virtue of time.
>> >
>> >No, it doesn't. It may be the case for Canonical that the LTS
>> >version has more support machinery, but the concept of LTS is just
>> >that it will be supported for a guaranteed amount of time, and not
>> >retired early, such that adopters can be sure that for a specific
>> >duration they will not have to upgrade to get support and patches.
>>
>> So developers will obviously have an incentive to develop a LTS
>> for free... not really seen this working well before honestly. And
>> I have been working in linux distros for some time.
>
>They will have the same incentive that they do for any release. Why
>would they decide not to work on it just because they are not being
>paid? They're not being paid for any of their other work anyway.

Ah. You seem to ignore 1) the itch to scratch 2) money as an
incentive. To think that they are not paid for any of their work is
both factually wrong and dangerous. At least within the LibreOffice
project and many others as well developers are paid directly or
indirectly for their work on libreoffice.

This is missing my point, which was that LTS doesn't mean there is
"more support machinery" requiring special contracts, and therefore
necessarily an LTS version is a version paid for by some company or
companies, but that LTS is simply a version that will be around for
longer, for whatever reason. People may or may not choose to work on an
LTS version, but certainly a big support contract isn't the only reason
they ever would.

So your points above don't really count either for or against what I
was trying to say, but in this context:

2) If developers are being paid, then the person/organisation paying
can decide what to pay them for, so can decide to pay them to maintain
an LTS version. Whether the person/organisation has the funds to pay
for an LTS version without special support contracts or not isn't the
point.

1) It is both factually wrong and dangerous to assume that developers
only work because they are being paid or are scratching an itch. If
you're saying that an LTS version wouldn't hold their interest, I say
that if that were the case, assuming they aren't being paid (otherwise
see 2. above), they would never work on the "Still" branch. Why would
they if it is boring? They do because it isn't only about what is the
flavour of the moment for them. They also have at least some sense of
duty to the project, and work on things that are necessary even if it
isn't the most interesting. If they didn't the project would quickly
fall apart. So if they have decided that an LTS version is important,
they will devote some time to it even if no one is paying them and
there are newer development branches to work on.

If by all this you are trying to say that LO doesn't have the funding
nor the developer resources to afford an LTS branch, that may well be
the case. It may even be the case for open source projects in general.
But that doesn't change the fact that the concept of an LTS version has
nothing to do with the business deals behind it.

Hi Tom,

I will try to rephrase it... Fresh is going to be renamed to Still (Stable) after a while. Bugs not found in Fresh will land in Stable within 6M... So the quality of the Stable will decrease if less people use the Fresh branch... So we need to find bugs early in the cycle ( when it is in the Fresh " state" (even better in the RCs and Betas before it is the Fresh release)). Developers need time to fix bugs, so it would be ideal to work with a daily build from time to time to ensure the correct function there (daily build is from master branch). ( sorry, I am involved in QA. I "do not care" if a user is able to submit a bug, we have so many bugs to take care. It is important that more advanced users (who know what a Bug in a software means) uses the Fresh branch. I just want to point out, that we have many bug reports, when we release a "Fresh" branch and that the feedback is more valuable at the beginning of the life- cycle then at the end....

Sorry that this resulted in one paragraph (typed from iPad).... To cut it short: We need early feedback in order to have time to improve the software quality.... I hope I was able to carry across _my_ point... (I know, from a marketing prospective not perfect :wink: )... If not, please ask :slight_smile:

Liebe Grüße, / Yours,
Florian Reisinger

Hi Tom,

If we do not find the bugs in the fresh version, they won't be
resolved until the rename to Stable/Still. If less use Fresh, the
quality of the next stable will be lower.... Does this help?

That is true, but it still seems dangerous to push new users towards
Fresh. If users start with Stable, then, after learning that it is
stable, are pushed towards Fresh to get newer features, then the ones
who want stability won't move across and will be happy, and the ones who
want new features will move, knowing there is stability to fall back
on, and so will also be happy. Should they find that everything works,
they will be happy with new features, and should they find instability,
they will be happy to fall back on the stable version, knowing that
they had taken a *slight* risk.

Conversely, if you push all new people to Fresh, any who find no bugs
will be happy, but any that find bugs will have the impression that LO
is buggy and unstable, and won't necessarily know about Stable to fall
back on. Those that are told about Stable will undoubtedly grumble
about the fact that they should have been told about it in the first
place.

I'm not saying that this is a simple matter, just that in my opinion it
is far better to offer the Stable branch as the default install, and
urge users to try out the Fresh branch when they start asking about
features. Once they've gotten as far as asking about features, they're
already far enough in the process to get help should there be any
unexpected problems with Fresh. Also, giving proper explanations (well,
proper brief explanations with a link to a more detailed explanation) on
the download page lets new users evaluate the choice themselves, and
that way they are less likely to be angry when caught out by something.

There should still be enough users of Fresh in this scenario to allow
for the needed user testing.

Paul

Hi Florian,

Hi Tom,
[...]

Thanks for your encouraging attempts to explain over and again.
I would expect that only for newcomers those items could ask for _some_
explanation.

Cheers,
Cor

Just to add another point... (see inline)

> Hi Tom,
>
> If we do not find the bugs in the fresh version, they won't be
> resolved until the rename to Stable/Still. If less use Fresh, the
> quality of the next stable will be lower.... Does this help?

That is true, but it still seems dangerous to push new users towards
Fresh. If users start with Stable, then, after learning that it is
stable, are pushed towards Fresh to get newer features, then the ones
who want stability won't move across and will be happy, and the ones
who want new features will move, knowing there is stability to fall
back on, and so will also be happy. Should they find that everything
works, they will be happy with new features, and should they find
instability, they will be happy to fall back on the stable version,
knowing that they had taken a *slight* risk.

Conversely, if you push all new people to Fresh, any who find no bugs
will be happy, but any that find bugs will have the impression that LO
is buggy and unstable, and won't necessarily know about Stable to fall
back on. Those that are told about Stable will undoubtedly grumble
about the fact that they should have been told about it in the first
place.

I'm not saying that this is a simple matter, just that in my opinion
it is far better to offer the Stable branch as the default install,
and urge users to try out the Fresh branch when they start asking
about features. Once they've gotten as far as asking about features,
they're already far enough in the process to get help should there be
any unexpected problems with Fresh.

They're also far enough along in the process to offer bug reports...