| Summary: | Auto update option to search only for major updates | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Thomas Bertels <tbertels+bugzilla> |
| Component: | UI | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | ilmari.lauhakangas, jorendc, kendy, pmladek, thb |
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=98999 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 108528 | ||
|
Description
Thomas Bertels
2012-09-26 06:53:03 UTC
Mmh, I don't agree to this. When we only ping users for new major versions (like 4.0.0) they'll download the 'point 0' (4.0.->0<-) version which is still recommended for testing. The 'point 1' version (4.0.1) is still not recommended for business critical use, so we have to make it that way we only warn/ping users when there is a second or third.. these versions are quite more stable. Still, I'm not convinced. @Petr: Following the ESC minutes you are our release engineer :-), you mind commenting on this one please? Kind regards, Joren That notification trigger could and should be set manually when the release engineer feels confident enough to make all users upgrade. I add Kendy into CC who did setup the update mechanism.
First, lets clear up the version naming convention. The version X.Y.Z consists of:
+ X - major version - new major release appears every few ears; brings new features and
even very big ones; the initial release usually brings some regressions
+ Y - minor version - new minor release appears every half a year; brings new features and
many fixes; the initial release usually brings some regressions
+ Z - micro versions - few bug fix releases appears regularly after each major or minor release;
these contain only selected bugfixes; we do our best to fix regressions, critical, annoying,
or trivial bugs and do not cause new regressions => each new bugfix release is more
stable than the previous one
AFAIK, we use the following strategy now. X.Y.Z users are informed when:
+ X.Y.Z+1 - any new bugfix release of the same major and minor release is available,
e.g. 3.5.3 user is informed about 3.5.4, 3.5.4, 3.5.6
+ X.Y+1.Z - new minor release of the same or higher micro version (bugfix-release level) is
available; e.g. 3.5.3 user is informed about 3.6.3, 3.6.4, 3.6.5, 3.6.6; this user
is not informed about 3.6.2 because the 2nd bugfix release has lower level of
stability than the 3rd one.
+ X+1.0.Z - new major version of the same micro version is available; same logic as with
minor release; it appears 6 months after the last minor release, so we do not
expect any real revolution and unstability
So, it might be possible to add a checkbox whether the user want to be informed about bugfix release or about minor releases on the same bugfix level.
|