Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index

On 07/28/2013 04:33 PM, Robinson Tryon wrote:
[cc'ing QA, as they might have some suggestions here...]

On Sun, Jul 28, 2013 at 12:16 PM, Kracked_P_P---webmaster
<> wrote:
I do not know that 4.1.0 would be the best to start a user on,
personallythat is.  Some would say 3.6.7 would be best for business users,
but does it have theMSO XML format updates that 4.0.4 and maybe 4.1.0 have?

Personally, I would tell peoplesomething like the following.
3.6.7 - the most conservative version
4.0.4 [4.0.5] - useful for most users
4.1.0 - for users that are early adopters for a version line

If we did this, we'd need to be clear that only the newest version has
certain features and updates, so we don't have users filing bugs or
asking questions about some feature that they read about in a blog
post or Release Notes.

But we do not want to have users that need the most stable version download and install the "early adopter version"

There has always been a "sticking point" for me to see the download page
default to an "early adopter" version, as named by the release plan page.
The more people on the early-adopter version, the faster we find bugs
and regressions. I think that if we make the tradeoffs clear, we'll
probably still have a large number of people grab the latest version
and help us find any remaining issues, but anyone who is more cautious
can stick with something from the previous Release series.

YES, we need to make it very clear what type of version they are getting.

I am not saying to install 4.0.3 instead of 4.0.5, but not everyone will want to be an early adopter and help find all the new bugs and such on a .0 version.

Yes, we need people to be early adopters, but do we want business users or others that should not be early adopters and bug finders be given the 4.1.0 version as their first look at LO? Would it be better for them to see 4.0.4 or even 3.6.7 before the first version of a new line?

We need more clarity to our newest users on what each version will do for them. Most may not be happy with the role of bug finder.

As for EOL versions. . . The Release Plan states that 3.6.7 was available
last week but in 2 week it will be at its "end of life".  Unless people read
farther, and that text may be confusing to some, they may get the idea that
3.6.7 will not be "supported" after August 15 of this year.
That's basically correct.

There are some L3 providers and distros (RHEL and Ubuntu come to mind)
who are still providing support on the 3.5 and 3.6 branches, but when
we say 3.5 is End of Life, we mean no more bugfixes from
TDF/LibreOffice for that release series.

This isn't a hosted piece of software like Office365 or Google Docs,
so we're not going to pull the plug on them when the software reaches
EOL, but if they report a bug in 3.5.7 today, they'll need to upgrade
to 3.6 or 4.x to see a fix for it.

(Again, if they're using 3.5.7 on Ubuntu 12.04, Canonical *may* decide
to backport a fix for the bug, but that's totally up to the distro,
not us)

Sure we would like to have people upgrade to
4.0.4 or 4.0.5, but I do not think we should have anyone think we will not
support aprevious product line less than a month or two after its last
version comes out.
IIRC, that's the timeline that ESC came up with. As I understand the
logic, the last few builds in a Release series are really just
maintenance releases containing bugfixes, etc... I believe the hope is
that users will start to transition to a new Release Series by the
time it has a 2nd or 3rd build. So instead of thinking about it as
dropping support a month after the last build, think about it as
dropping support 5 months after the 5th build (X.x.4) in a series.

To take 4.0 and 4.1 as an example, Early Adopters will grab 4.1.0
right now while more cautious users/deployments will stick with 4.0.4
and start to test 4.1.0. At the end of August, cautious users will
test 4.1.1 and, if it's not ready, continue with the 4.0 branch and
download 4.0.5. Hopefully most people will move when 4.1.2 or 4.1.3 is
released, the latter of which comes out a week after the last build of

The Detailed Schedule pages are a little more descriptive of the build
lifecycle, but perhaps we could be even more clear by tweaking the
presentation of the build dates to make it clear that, unless you've
got a separate support structure/contract in place, you should be
transitioning off of a Release series at or *before* the last build in
that series is released.

I really think after "ending" 3.3, 3.4, 3.5, and now 3.6 as a line, we
should have some better way to guide our new users to choose which version
they should try for their first time downloading and using LO.
A short and sweet guide could be a great improvement here! To our
credit, I think that most first-time users don't encounter any major
problems with LibreOffice, even if they are using the first build in a
Release series. Just a gentle nudge in the right direction should be
all we need to do :-)


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.