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

On Sun, Jul 28, 2013 at 04:33:45PM -0400, 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


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.

See also about user confusions
about our versions in the context of the automatic "available update"
notification. Our "vision" really needs to be "taught"; in the context
of the update notification, I suggest we add a setting:

 - conservative
 - "most users"
 - early adopter

and the setting screen should contain a brief explanation of the

Right now, we "heuristically" say (for our update policy) that people
using 3.6 are "conservative" (and propose them "only" 3.6.7), but
really that's a (bad) heuristic; it should be a setting.

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... (*...) 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.

Precisely. The last build is *by* *definition* the time when you drop
the possibility for bugfixes. Releasing a bugfix needs a new build, so
if you say "we may make a bugfix to 3.6.7", it means "we may make a
3.6.8" or in other words "3.6.7 may not be the last 3.6 build".


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.