Bug 36437 (LO-dev-builds) - Developer builds should contain another namespace, e.g. LibO-future (allow parallel installation of development versions, keeping the stable release)
Summary: Developer builds should contain another namespace, e.g. LibO-future (allow pa...
Alias: LO-dev-builds
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
(earliest affected)
Hardware: All All
: highest blocker
Assignee: Not Assigned
: 36575 37369 (view as bug list)
Depends on:
Reported: 2011-04-20 15:12 UTC by Andreas Mantke
Modified: 2011-05-19 13:28 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Mantke 2011-04-20 15:12:18 UTC
It is very important that our community members could test the nightly builds without any risk for the productive user / profile. I tested one of this builds with my current user and get issues with the user profile. It doesn't work correctly with my LibO 3.3.x anymore. In my case it affected an extension (the Presenter Console) and I was only aware of this issue, because I had to give a presentation about LibreOffice (and use the second monitor).

Because of such possible side effect I propose a different namespace and a different profile for the nightly build (like in the OOo project). We should name it more interesting, e.g. LibO-future. We need more people who install and use the development builds on their desktops, so that we could get feedback early and often, if something went wrong within the code.
Comment 1 Don't use this account, use tml@iki.fi 2011-04-20 23:17:29 UTC
Good idea, can we expect you to help in implementing that?
Comment 2 Andreas Mantke 2011-04-21 00:45:01 UTC
@Tor: I can test it, but I can't implement it. I'm working currently on another important sub-project for LibO and have no time to examine, where the necessary changes had to be done.
Comment 3 Christian Lohmaier 2011-04-24 14:47:13 UTC
There should not be anything necessary except to not build the openoffice targets, but the openoffice-dev targets in instsetoo_native/util

ALLTAR : openofficedev_$(defaultlangiso) ooolanguagepackdev $(eq,$(OS),MACOSX $(NULL) ooohelppackdev)

instead of the default

ALLTAR : openoffice_$(defaultlangiso) ooolanguagepack $(eq,$(OS),MACOSX $(NULL) ooohelppack)

As building dev-versions is the more usual task, the dev-named variant should be made the default, and the non-dev variant be activated with --enable-release or something.

Anyway, to check whether the building of dev variant works for libreoffice, or whether there needs to be changes needed, build LO, and after regular building, source the environmentfile, cd instsetoo_native/util and run dmake openofficedev_en-US - this should produce the libreoffice-dev version of the installer.
Comment 4 Christian Lohmaier 2011-04-25 03:56:27 UTC
*** Bug 36575 has been marked as a duplicate of this bug. ***
Comment 5 Ed 2011-04-25 04:20:05 UTC
Changed "Nightly" to "Developer" as this applies to beta as well as nightly builds.
Comment 6 Bernhard Dippold 2011-04-25 06:36:13 UTC
This topic is not only important for our community members, but for our marketing and public recognition too.

If we want external people to test our release-early / release-often cycle, installing a test/daily/beta version should not lead to deinstallation of the version of LibreOffice they use for productive work. Similar problems might happen to their user profiles.

We can't expect an average user to set up a virtual machine or create a test user account to avoid such interaction. 

We got negative public feedback on our first Beta, now it's the same for the present Beta. If we can't change the product's behavior in short time, we should modify our website to describe different installation processes for final releases and developer/tester builds.

Developers: Please check if this topic qualifies for an "Easy Hack" - and if nobody considers it to be important enough to work on it, tell us, so we can modify our website (perhaps leading to less testers, but to less negative feedback as "premature project" too).

All: Do you think this topic is worth to be linked to the "most annoying bugs" (BUG 35673)?
Comment 7 Ed 2011-04-25 06:46:57 UTC
This issue by its very nature only affects developer builds, so I don't think it would make any sense to set it to block a stable release.
Comment 8 Andras Timar 2011-04-28 04:14:11 UTC
I patched openoffice.lst in master, so openofficedev target does not want to package JRE any more.
I built dev versions (en-US only) on Windows and on Linux without problems.

The --enable-release configure switch is yet to be implemented.
Comment 9 Ed 2011-04-29 08:41:07 UTC
This is not a medium priority enhancement request.  It is essential for developer builds to be installable alongside stable versions to allow the product to be tested.  Setting a more appropriate importance.
Comment 10 Don't use this account, use tml@iki.fi 2011-04-29 08:59:36 UTC
And since when does an anonymous bugzilla commenter get to decide?
Comment 11 Andras Timar 2011-04-30 13:26:21 UTC
In master I introduced a new switch to configure: --enable-release-build
Default is dev build with dev prefixes all around.

For 3.4 we'll not have more betas (or will we?) so I would not disturb that branch.
Comment 12 Friedrich Strohmaier 2011-04-30 13:52:07 UTC
It'd be great to have it already for 3.4!

I assume many many people out there beeing keen to install the 3.4 prerelease to satisfy their couriousity and to give feedback about issues they encounter.

As 3.4 from my point of view, is widely considered the very first child of genuine libreoffice development. This way we might profit from more eyes power resulting in a more refined release.

One more thank You for the great work done so far.

Comment 13 Duncan Lithgow 2011-05-09 01:15:31 UTC
Why is this marked RESOLVED FIXED? LO 3.4 beta 4 still overwrites previous versions.

I don't remember specifically where - but someone has added a note that installing LO 3.4 beta 4 will replace earlier installations. So we are being warned at the moment. 

The next issue might be how a user can see in their application menu which version is stable and which is not - most places in Windows and Linux the version is not usually mentioned, just the application name. It might be good to have some visual indication on the application icons. This is especially relevant with Widnows / and the Ubuntu Unity desktop encouraging keystroke launching of application. Just my thoughts on this.

Thanks for the great progress LO has already made - I've noticed a few silly things disappear which bugged me about OOo.
Comment 14 Christian Lohmaier 2011-05-09 03:26:28 UTC
This process will not be used for 3.4[.0] - the next build is already planned to be a rc = release candidate, and those are supposed to behave exactly like the final version, thus you would have had a dev-build just for one single build, and that would be confusing at best.

for the next releases, the dev-builds will be used and hence will make it much easier for testers/QA/interested users to follow the nightly builds/start earlier with QA for the release without having to worry about removal of the stable version.
Comment 15 Don't use this account, use tml@iki.fi 2011-05-19 13:28:41 UTC
*** Bug 37369 has been marked as a duplicate of this bug. ***