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
webmas...@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
--
To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/website/
All messages sent to this list will be publicly archived and cannot be deleted
