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)
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.
Setting high importance for this enhancement given target goal of a 4.0.3 build.
You can test it right now, just choose custom install, and install LibreOffice into c:\Program Files\LibreOffice\.
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?
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
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.
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.
(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 ;)
(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?
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.
(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.
So might be useful to do this change for LO 6.
(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.
(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.
(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?
(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.)
(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?
(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.
I am fine with waiting until 6.0. It would just be nice to be heading in that direction in the future.
(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
A patch is in gerrit: https://gerrit.libreoffice.org/40957
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.
Following the Mike's patch, let's put this one to FIXED since it'll concern LO versions >= 6.0.0 only.
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
Added a release note: https://wiki.documentfoundation.org/ReleaseNotes/6.0#Windows
*** Bug 92245 has been marked as a duplicate of this bug. ***
:-( On linux at least it seems this change has the consequence of having to now manually move user settings, extensions, and macro libraries to the new version 6, a non-trivial task. As near as I can tell from version 5 to 6 there are no changes required in the user settings, extensions, or macro libraries. Ref: https://ask.libreoffice.org/en/question/141322/when-upgrading-to-lo-60-whats-the-best-way-to-migrate-the-my-macros-standard-library/ But that notwithstanding, I think there should be: a) A multi platform installer for LO (instead of by different methods on different systems), and b) That installer should be able to migrate user content when upgrading if appropriate. Possibly it could even automatically modify or a least flag needed changes from version to version.\ I find it frustrating to see an issue on Windows be fixed, only to make a new problem for Linux.
(In reply to Howard Johnson from comment #27) The change that made it to 6.0 doesn't touch a single bit in Linux builds. If you have some problem, please file a separate bug report, where describe the details of the problem, your OS, which package did you try (TDF-provided - RPM/DEB; distro-provided; self-built...). Wrt "single installer": most Linux distros have their own builds of LibreOffice, that aren't identical to TDF builds both in terms of baseline, dependencies, and build options (integration, extensions, extras etc.). They are distributed using the distros' package management systems, their install directories are defined by package maintainers, and application is manageable by system administrators of those systems using well-integrated tools. Windows installer used by TDF for LibreOffice distribution uses system-standard MSI technology, that allows the application to be managed using familiar interface, and integrate well into platform's technologies like ActiveDirectory application deployment. Wasting TDF resources to some monstrous cross-platform installer would not only be wasteful, but also will create difficulties deploying application in both end-user and corporate environment, to no benefit at all.