[Libreoffice-qa] [libreoffice-website] Update from 3.6.7 as EOL

[Lionel Elie Mamane]

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
> <webmaster at krackedpress.com> 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

> +1

>> 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 https://bugs.freedesktop.org/67556 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
trade-offs.

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".

-- 
Lionel