Bug Hunting Session
Bug 55347 - Auto update option to search only for major updates
Summary: Auto update option to search only for major updates
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Help-Menu
  Show dependency treegraph
 
Reported: 2012-09-26 06:53 UTC by Thomas Bertels
Modified: 2017-07-13 12:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Bertels 2012-09-26 06:53:03 UTC
Currently, the automatic search for updates will warn the user even for a small version change (i.e. from 3.5.3 to 3.5.4).

As most users won't feel it's worth to download the 200 MB install for it, they will be continually bugged by that auto update check feature.
Eventually, they may disable it to avoid the annoyance.

An option to search only for major updates would allow these users to stay aware of major version which they're willing to install.
Comment 1 Jorendc 2013-05-19 18:18:05 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
Comment 2 Thomas Bertels 2013-05-20 12:47:10 UTC
That notification trigger could and should be set manually when the release engineer feels confident enough to make all users upgrade.
Comment 3 Petr Mladek 2013-05-20 14:53:24 UTC
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.