Problem description: Libreoffice says that it is up to date even when a new release is available. Currently on 4.3.1.2 and 4.3.2.2 is available for download. I also had this problem with 4.3.0 and manually updated. Steps to reproduce: 1. Click Help -> Check for Updates 2. Wait for check to finish Current behavior: Says: 'LibreOffice 4.3 is up to date.' Expected behavior: Should say that updates are available. Operating System: Mac OS X Version: 4.3.0.4 release
It is not a bug. The script which manages the updating is activated for the version "Stable" (currently the 4.2 branch). In the case of the branch "Fresh", it is generally activated for the third bugfix. If you install the "Fresh" branch, you are supposed to be an early adopter who is aware of the release dates of bugfixes: http://wiki.documentfoundation.org/ReleasePlan Best regards. JBF
(In reply to comment #1) > It is not a bug. The script which manages the updating is activated for the > version "Stable" (currently the 4.2 branch). In the case of the branch > "Fresh", it is generally activated for the third bugfix. Hm. That’s not obvious at all :-) If that is specified somewhere, then we should do a better job explaining it to users. It’s not even mentioned on the website. As a user I would expect that the update checker would also update my “Fresh” version, otherwise why is it present in the software at all?
*** Bug 84459 has been marked as a duplicate of this bug. ***
*** Bug 84471 has been marked as a duplicate of this bug. ***
Should there not be two channels (Fresh and Stable) which would allow the Fresh channel to be updated without the Stable being updated to Fresh? It just makes it easier for people to use the Fresh channel and keep up to date with the latest version.
*** Bug 84549 has been marked as a duplicate of this bug. ***
@JBF I do not agree and I share Adolfo thoughts about it. maybe we should change that script in this way 1- identify current LibO version 2- if user has LibO stable then check for newer stable releases of for fresh releases higher than .3 3- if user has already LibO fresh then check for any newer fresh release regardless of the number so in the actual scenario I'd expect that a 4.2.5 user to be suggested by the script to upgrade to 4.2.6, while a 4.3.0 user to be suggested to upgrade to the 4.3.2 release. so consider reverting the issue status from NOTABUG to NEW edited summary notes
(In reply to Adolfo Jayme from comment #2) > (In reply to comment #1) > > It is not a bug. The script which manages the updating is activated for the > > version "Stable" (currently the 4.2 branch). In the case of the branch > > "Fresh", it is generally activated for the third bugfix. > > Hm. That’s not obvious at all :-) If that is specified somewhere, then we > should do a better job explaining it to users. It’s not even mentioned on > the website. It is only what I deduce from ESC reports on developers mailing-list each Thursday. Best regards. JBF
ok, but the bottom line is that a 4.3.0 or 4.3.1 user should be prompted to upgrade to 4.3.2 if clicking the check for update button
Not a bug? Well I am using LibreOffice Fresh only, but I am not aware of the release dates (and should I be?)... If that's the case, then why I have this option at all? Since "Check for updates" is not usable for me, then just remove it. There is no sense in this. Fresh installation should check for updates for the Fresh branch. Stable should check for stable updates I think.
So what is the easiest way to update the Fresh channel? Just download and reinstall? If so what is the point of the Check for Updates in the Fresh channel? Sorry for all the questions haha.
platform --> ALL I'm still thinking that the RESOLVED NOTABUG is not a correct label
*** Bug 85034 has been marked as a duplicate of this bug. ***
(In reply to tommy27 from comment #12) > platform --> ALL > > I'm still thinking that the RESOLVED NOTABUG is not a correct label It is not a bug because it works as designed. If you think it should works differently, please file an enhancement request with an explanation how (and why) the updater should work, depending on the version installed and the version available in each branch. For example: # If the user is on the Fresh branch: propose to install each bugfix of the Fresh branch as soon as it is available # If the user is on the Stable branch: propose to install each bugfix of the Stable branch as soon as it is available # If the user is on the Stable branch and the Stable branch reaches its End_Of_Life (~last bugfix): propose to jump to the Fresh branch. The last point is the most critical from a marketing point of view: what is the best time to [suggest to] jump from Stable to Fresh branch, knowing that the Fresh branch will become the Stable branch with the release of the next main version (x.y.0, e.g. 4.4.0). Please open a new bug report as enhancement with a clear proposition in the description. Otherwise all the discussion will be confusing. Best regards. JBF
> (In reply to tommy27 from comment #12) > .... If you think it should works > differently, please file an enhancement request with an explanation how (and > why) the updater should work, depending on the version installed and the > version available in each branch. > For example: > # If the user is on the Fresh branch: propose to install each bugfix of the > Fresh branch as soon as it is available > # If the user is on the Stable branch: propose to install each bugfix of the > Stable branch as soon as it is available @JBF that's exactly what I've already proposed few comments ago. see below: (In reply to tommy27 from comment #7) > ... > so in the actual scenario I'd expect that a 4.2.5 user to be suggested by > the script to upgrade to 4.2.6, while a 4.3.0 user to be suggested to > upgrade to the 4.3.2 release. > ... you correctly pointed out that there's a corner case here: > # If the user is on the Stable branch and the Stable branch reaches its > End_Of_Life (~last bugfix): propose to jump to the Fresh branch. > > The last point is the most critical from a marketing point of view: what is > the best time to [suggest to] jump from Stable to Fresh branch, knowing that > the Fresh branch will become the Stable branch with the release of the next > main version (x.y.0, e.g. 4.4.0). as far as I know, correct me if I'm wrong, actually the end-of-life users of 4.2.x whose latest release will be 4.2.7 (end of october '14) will be prompted to update to 4.3.x only once the 4.4.0 will be released (early february '15), at that time LibO 4.3.5 will be available. see: https://wiki.documentfoundation.org/ReleasePlan so why not keeping the same behaviour? > Please open a new bug report as enhancement with a clear proposition in the > description. Otherwise all the discussion will be confusing. > > Best regards. JBF I really don't see the point to open a new report as it seems that there's nothing confusing here... please, don't misunderstand the tone of my words... I'm not attacking you, I'm just expressing a different opinion than you, all the bug reporters (including those of the multiple duplicates), Adolfo Jayme (who's an experienced community member) and me too think that's not obvious at all that the script doesn't prompt LO fresh users to upgrade once new release are available. considering the "instability" of the LO Fresh early version, any upgrade should be instead "strongly" suggested.
(In reply to tommy27 from comment #15) > considering the "instability" of the LO Fresh early version, any upgrade > should be instead "strongly" suggested. Exactly. +10000. You all surely have noticed that the first bugfix release of every branch (e.g., 4.3.1) contains more than a hundred fixes found in the dot-zero release. Surely we want to get all of these fixes out immediately. But instead we’re hiding the fixes and we’re receiving bug reports of users still using the dot-zero release.
@Adolfo given the amount of duplicates I suggest to move this to mab4.3 list. if we don't change the "check for updates" criteria, users of the 4.3.0 fresh unaware of our release schedule will be prompted to update just only when the 4.3.x turns stable which should be 4.3.5 (february 2015) just soon after the release of LibO 4.4.0 that means almost 500 bugfix later than early 4.3.0
(In reply to tommy27 from comment #15) [...] > I really don't see the point to open a new report as it seems that there's > nothing confusing here... It is only a problem for QA workflow. It is confusing to change from bug to enhancement request. To understand that there is proposition and where it is you have to read all the comments. I think it is far more clear to close this one and open another one with a description presenting the enhancement. Of course this enhancement should refer to this bug report and its duplicates. Best regards. JBF
It did not work as designed. The problem was that in update.libreoffice.org/check.php a few versions were missing: 4.3.0.2, 4.3.0.3 and 4.3.0.4. I added these versions now. Also 4.3.2.1 and 4.3.2.2 were missing, and the latest from 4.3 branch was set to 4.3.1.2. I corrected this as well. I guess this bug report should have been files to TDF Redmine instead, because it is a job of a TDF release engineer, not of a developer. This check.php has to be updated regularly, otherwise we'll see similar bug reports after release of the upcoming 4.2.7 and 4.3.3.