Currently the 'Install' button in the update dialog is never activated. It is because we do not provide automatic download of new version. In order to be able to have this functionality, we need to make sure that the download is safe - that the cannot get a binary from some malicious site instead. The code needs review & update in case there are dangerous bits there; then we can enable this.
MAB - as discussed at the ESC.
Short term, we should at least update the help: https://help.libreoffice.org/swriter/EXTENSIONS_HID_CHECK_FOR_UPD_DLG
Fix priority for MABs.
@Jan is this MAB still reproducible with 4.3.x releases?
(In reply to Jan Holesovsky from comment #0) > Currently the 'Install' button in the update dialog is never activated. CONFIRMED with 4.3.2.2 + Ubuntu 14.04 REPRO: 1) Open LibreOffice 2) Help -> Check for updates. RESULT: LO 4.3.4 is offered for download, but the 'Install' button stays grayed-out
Can we consider using Sparkle/WinSparkle instead?
(In reply to Adolfo Jayme from comment #6) > Can we consider using Sparkle/WinSparkle instead? That could be another idea for GSoC. Integrating Sparkle would fix some long-requested enhancements: it supports diff-based (incremental) updates, avoiding huge downloads (bug 54242); it supports displaying release notes (bug 69042)… Also, Sparkle is an actively maintained project, and integrating it would reduce the burden in maintaining our custom mechanisms.
hi Adolfo, is the "Reuse Mozilla's rolling update mechanism for LibreOffice" in the GSOC 2015 projects something related to this? https://wiki.documentfoundation.org/Development/GSoC/2015
Update from GSoC 2015 wrapup from http://bosdonnat.fr/gsoc-2015-wrap-up.html Mozilla update system for LibreOffice from Nathan Yi Although Nathan did not have time to fully implement the UI and server-side backend components of the project, he managed to do in-place upgrades of LibreOffice using full and partial (version-to-version) patches. These patches can optionally be signed for secure transport over the Internet. Wiki entry: https://wiki.documentfoundation.org/Development/GSoC/Ideas#Reuse_Mozilla.27s_rolling_update_mechanism_for_LibreOffice
*** Bug 99268 has been marked as a duplicate of this bug. ***
*** Bug 62637 has been marked as a duplicate of this bug. ***
*** Bug 105619 has been marked as a duplicate of this bug. ***
I am curious about the status of this issue. It's been active since 2014 and no apparent progress or news since 2015.
linux and windows have seen work on using MAR updater for LO. Sadly that effort has not taken macOS into account.
Is this issue still open?
I am currently using LibreOffice 6.0.1 on Win 10 and I am still experiencing this bug.
Still exists in version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Automatic updates were implemented by Markus Mohrhard, please see - https://mmohrhard.wordpress.com/2017/08/22/announcing-automatically-updating-daily-windows-libreoffice-builds/ - https://mmohrhard.wordpress.com/2017/06/21/announcing-automatically-updating-libreoffice-builds/ although they are not used in production releases, yet.
Changing priority back to 'medium' since the number of duplicates is lower than 5
*** Bug 125451 has been marked as a duplicate of this bug. ***
*** Bug 144426 has been marked as a duplicate of this bug. ***
Considering the duplicates, shouldn't the bug priority be updated?
*** Bug 151466 has been marked as a duplicate of this bug. ***
What about removing the "install" button waiting for the implementation of the lacking code to implement it?