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.
Good idea, can we expect you to help in implementing that?
@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.
There should not be anything necessary except to not build the openoffice targets, but the openoffice-dev targets in instsetoo_native/util i.e. 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.
*** Bug 36575 has been marked as a duplicate of this bug. ***
Changed "Nightly" to "Developer" as this applies to beta as well as nightly builds.
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)?
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.
I patched openoffice.lst in master, so openofficedev target does not want to package JRE any more. http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=3637bca71d7b60aeeda839b0cb4a047e282b96f6 I built dev versions (en-US only) on Windows and on Linux without problems. The --enable-release configure switch is yet to be implemented.
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.
And since when does an anonymous bugzilla commenter get to decide?
In master I introduced a new switch to configure: --enable-release-build Default is dev build with dev prefixes all around. http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=70a55ac39511fba746db26cede8ce97bc01af461 For 3.4 we'll not have more betas (or will we?) so I would not disturb that branch.
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. Friedrich
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.
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.
*** Bug 37369 has been marked as a duplicate of this bug. ***