Bug 62303 - Enhancement request: Set default install folder under Windows to \LibreOffice\
Summary: Enhancement request: Set default install folder under Windows to \LibreOffice\
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Windows (All)
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard: target: 4.1.0 target:4.1.0 target:6.0.0
Keywords:
: 92245 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-13 17:33 UTC by Pedro
Modified: 2017-12-21 21:56 UTC (History)
14 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 Pedro 2013-03-13 17:33:44 UTC
Since under Windows installing a new version requires that the previous version is uninstalled, it would follow Windows applications common usage that the new version is installed to the same folder (e.g. \LibreOffice\) instead of version named folders.

In addition this would have the advantage of keeping All Users extensions functional after an update from a .x and even x. level version. Currently updates keep Current User extensions only.

Targetting version 4.0.3 (one month from now) would allow to test with RC builds before the switch to 4.1.0 (which would make updating to 4.2, 4.3, 4.x and 5.x a non-issue)
Comment 1 V Stuart Foote 2013-03-14 02:05:23 UTC
Pedro, I think this IS an excellent idea if there are no installer packaging issues. Lets poke the dev and users lists to see if anyone has substantive objections.

Should note though that as it is now, until 4.0.3 RC1 is finalized, the TinderBox daily builds default to install to \LOdev4.0\ and also must have an installer command line value of WRITE_REGISTRY=1 to fully integrate into the Windows Registry.

Andras, assuming no substantive push back is there a good point we can start testing a non-versioned Windows installation directory ahead of RC1? Don't expect we'd have issues with the installer, but we'd need to look at what happens to the non-bundled extensions and behavior of LibreOffice registry during migration.
Comment 2 V Stuart Foote 2013-03-14 03:19:45 UTC
Setting high importance for this enhancement given target goal of a 4.0.3 build.
Comment 3 Andras Timar 2013-03-14 07:01:53 UTC
You can test it right now, just choose custom install, and install LibreOffice into c:\Program Files\LibreOffice\.
Comment 4 Petr Mladek 2013-03-14 16:38:24 UTC
So, there are two versioned paths:

   + user configuration uses major version, e.g "LibreOffice/4"
   + default system installation directory use major+minor version, .e.g "LibreOffice 4.0"

Proposed changes:

   + user configuration path:
          + leave it as is for all 4.x releases
          + later decide to switch to non-versioned patch with 5.0 release

    + system installation path:
          + leave it as is for 4.0.X bugfix releases
          + use only major version for 4.X minor releases => "LibreOffice 4";
             it will be in sync with the user configuration path
          + later decide to use non-versioned path with 5.0 release
 
In each case, I would do this change only on Windows and keep Linux as is. The versioned paths allows to easily install more versions in parallel there. It is not possible on Windows even with the versioned paths because of conflicting registry entries. Note that most Linux users use distro-specific builds that usually use non-versioned installation path. The upstream Linux packages are used there for testing or as a fallback.

Is anyone against this solution, please?
Comment 5 V Stuart Foote 2013-03-14 18:07:36 UTC
per ESC mtg ( http://nabble.documentfoundation.org/minutes-of-ESC-call-td4043820.html ) install directory to be adjusted to "LibreOffce 4" rather than dropping 4.x numbered versioning completely.

also won't adopt for 4.0.3

adjusting target to 4.1/Master
Comment 6 Commit Notification 2013-04-11 12:23:19 UTC
tinderbox committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca7cbe24cc497384d9b4f7d19d1fff3c84e3ea19

use only major version for the system installation path on Windows (fdo#62303)



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 7 Petr Mladek 2013-04-12 08:51:53 UTC
So, I have done the first step that was approved by ESC. It means to install LO 4.1and further 4.X releases into "LibreOffice 4" system directory. It should solve at least updates between 4.X minor versions.

The question whether to use non-versioned directories for 5.0 is still opened.
Comment 8 Pedro 2013-04-12 10:17:36 UTC
(In reply to comment #7)
> So, I have done the first step that was approved by ESC. It means to install
> LO 4.1and further 4.X releases into "LibreOffice 4" system directory. It
> should solve at least updates between 4.X minor versions.
> 
> The question whether to use non-versioned directories for 5.0 is still
> opened.

I think it's one good step forward. 5.0 will be out some 3 to 4 years from now. Hopefully by then a Mozilla style extension checker will have been added ;)
Comment 9 Stephan Bergmann 2015-04-20 07:14:21 UTC
(In reply to Petr Mladek from comment #7)
> So, I have done the first step that was approved by ESC. It means to install
> LO 4.1and further 4.X releases into "LibreOffice 4" system directory. It
> should solve at least updates between 4.X minor versions.

Can anybody confirm that this change indeed made extensions installed for all users keep working across minor LO 4.x versions on Windows?
Comment 10 sstory 2016-04-20 16:04:18 UTC
I just wanted to add to the idea.  As admin of various, mostly Windows, machines/users, I make shortcuts to Calc and Writer on all user's desktop or taskbar.  Not having the version number would also prevent these from needing to be recreated on major version upgrades.  I know the standard is to use the one app created shortcut and then choose between them. As a personal preference I prefer to just click the shortcut I want from the start. 

I do thank the ESC for at least dropping it to only have the major version number which is less trouble that it used to be.  I agree with the comment of dropping it only for Windows.  If it would cause no problems in doing so, I would see it as an improvement.

Thanks for further consideration of the enhancement to be just LibreOffice for the Windows install directory.
Comment 11 Justin L 2017-05-11 18:16:57 UTC
(In reply to Stephan Bergmann from comment #9)
> Can anybody confirm that this change indeed made extensions installed for
> all users keep working across minor LO 4.x versions on Windows?

I confirm with 5.x that an "all users" extension kept working across minor LO versions on Windows.

Specifically, I had 5.1.6 installed with user extension "C:\Program Files\LibreOffice 5\share\uno_packages\cache\uno_packages\lu700ktw7h.tmp_\wasta-ssg-defaults.oxt".  
I upgraded to 5.2.7 and confirmed that the extension still existed and functioned.
Comment 12 Stephan Bergmann 2017-05-12 06:51:40 UTC
So might be useful to do this change for LO 6.
Comment 13 V Stuart Foote 2017-05-12 12:56:28 UTC
(In reply to Stephan Bergmann from comment #12)
> So might be useful to do this change for LO 6.

Are we expecting any change to the .oxt/sdk framework at 6 that would benefit from delay? Otherwise, with 5.5 now in line, seems doing the directory change for the incremental at 5.4 would be just as valid--a brief pain point (accelerated a bit) and then it is over.
Comment 14 Stephan Bergmann 2017-05-12 13:05:17 UTC
(In reply to V Stuart Foote from comment #13)
> (In reply to Stephan Bergmann from comment #12)
> > So might be useful to do this change for LO 6.
> 
> Are we expecting any change to the .oxt/sdk framework at 6 that would
> benefit from delay? Otherwise, with 5.5 now in line, seems doing the
> directory change for the incremental at 5.4 would be just as valid--a brief
> pain point (accelerated a bit) and then it is over.

That would mean that shared extensions stop working when upgrading from 5.x to 5.4.  I guess user reception will be better when instead extensions stop working (one last time) when upgrading to 6.
Comment 15 V Stuart Foote 2017-05-12 14:06:50 UTC
(In reply to Stephan Bergmann from comment #14)
> That would mean that shared extensions stop working when upgrading from 5.x
> to 5.4.  I guess user reception will be better when instead extensions stop
> working (one last time) when upgrading to 6.

I guess it can wait then--will suck either instance for folks depending on a number of extensions.

Still needs a bit of planning--as here install should go to %ProgramFiles%\LibreOffice rather than %ProgramFiles%\LibreOffice 6.

But would think the LibreOffice user profile needs to drop the number directory. Rather than the current awkward %APPDATA%\LibreOffice\4 (leftover from the 3 -> 4 migration) it should become just %APPDATA%\LibreOffice, yes?
Comment 16 Stephan Bergmann 2017-05-12 15:03:31 UTC
(In reply to V Stuart Foote from comment #15)
> But would think the LibreOffice user profile needs to drop the number
> directory. Rather than the current awkward %APPDATA%\LibreOffice\4 (leftover
> from the 3 -> 4 migration) it should become just %APPDATA%\LibreOffice, yes?

No.  We once decided to stick with "4" as long as there's no technical reason of incompatibility that would force us to switch to a different name.  (We did so exactly to avoid migration issues.  And anyway, at least technically, the issue of UserInstallation naming is unrelated to this bug.)
Comment 17 V Stuart Foote 2017-05-12 15:17:50 UTC
(In reply to Stephan Bergmann from comment #16)
> (In reply to V Stuart Foote from comment #15)
> > But would think the LibreOffice user profile needs to drop the number
> > directory. Rather than the current awkward %APPDATA%\LibreOffice\4 (leftover
> > from the 3 -> 4 migration) it should become just %APPDATA%\LibreOffice, yes?
> 
> No.  We once decided to stick with "4" as long as there's no technical
> reason of incompatibility that would force us to switch to a different name.
> (We did so exactly to avoid migration issues.  And anyway, at least
> technically, the issue of UserInstallation naming is unrelated to this bug.)

Remember the discussion, but it didn't make sense to keep it then--and having had it for all of the 5 builds (looking like an oversight though we know it was not) maybe it is time for it to go? When crossing to 6 in 18 months, or do it sooner if this is done for 5.4 or 5.5--either way is the directory necessary to user profile?
Comment 18 Justin L 2017-05-12 15:54:57 UTC
(In reply to Stephan Bergmann from comment #14)
> I guess user reception will be better when instead extensions stop
> working (one last time) when upgrading to 6.

I completely agree on waiting since this matches administrators' expectations, and another benefit of waiting till 6.0 is that it gives more opportunity for a motivated person to write code to migrate the extensions to the new install.
Comment 19 sstory 2017-05-23 12:47:56 UTC
I am fine with waiting until 6.0. It would just be nice to be heading in that direction in the future.
Comment 20 Justin L 2017-06-14 11:53:52 UTC
(In reply to sstory from comment #19)
> I am fine with waiting until 6.0.

The current master will become 6.0 (as per https://cgit.freedesktop.org/libreoffice/core/commit/?id=893fe19fcdf5d3edefc4b19a021ebc2b11f5ab9f). So it would be nice for a Windows packager to make the necessary changes soon.  Of course, the benefits won't be seen until 7.0, but we don't want to wait or else we will break some 6.x or delay benefiting until 8.0
Comment 21 Mike Kaganski 2017-08-10 09:36:43 UTC
A patch is in gerrit: https://gerrit.libreoffice.org/40957
Comment 22 Commit Notification 2017-08-10 11:31:04 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef2e6260fad38e26c8591ea88ded348db618270d

tdf#62303: Drop version in installdir name for releases on Windows

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 Julien Nabet 2017-08-10 12:38:04 UTC
Following the Mike's patch, let's put this one to FIXED since it'll concern LO versions >= 6.0.0 only.
Comment 24 V Stuart Foote 2017-08-10 12:58:37 UTC
So the user profile will have some snags, e.g. pulling from full path to \shared for recently used templates, extensions, etc. rather than a $(brandbaseurl) variable.

We will need to either clean up those path changes with the installer or on first use with a script--or do we just force users onto a clean profile?

Either case the path change needs a release note entry.

Related, will we do anything for the residual user profile directory ...\LibreOffice\4, or is there continued agreement to carry the 4 forward into the LO 6 branch? see comment 16
Comment 25 Justin L 2017-10-21 18:06:42 UTC
Added a release note: https://wiki.documentfoundation.org/ReleaseNotes/6.0#Windows
Comment 26 Stephan Bergmann 2017-10-23 07:54:54 UTC
*** Bug 92245 has been marked as a duplicate of this bug. ***
Comment 27 Howard Johnson 2017-12-21 19:39:23 UTC Comment hidden (no-value)
Comment 28 Mike Kaganski 2017-12-21 21:56:10 UTC Comment hidden (off-topic)