openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <>
Subject Re: AOO 4.0 upgrade behaviors
Date Wed, 05 Jun 2013 12:57:18 GMT

here is what I know about some of the questions.

On 05.06.2013 13:36, Rob Weir wrote:
> I'm a little confused by recent threads on the upgrade logic.  But I'd
> like to ensure that this area is adequately tested and that we
> understand how it behaves so we can better support users.  So here are
> some questions to flesh out the way it will work with AOO 4.0.
> 1) When an AOO 3.4.1 user profile customizations configured, what
> happens when they install AOO 4.0?

For AOO 4.0 a new user profile will be created.
Currently (actual status of our code), nothing from an existing AOO 
3.4.x (or OOo 3.x) user profile will be migrated to the new AOO 4.0 user 

If we decide to solve issue 122397 we can decide what part of an 
existing AOO 3.4.x resp. OOo 3.x user profile is migrated.

> 2) If anything is not migrated are users given any warning, so this is
> not a surprise?  (Maybe we need something in the Release Notes at
> least?)

No warning is given to the user.

> 3) Does this include custom spell checking word list?  Old Extensions?

I think the question is meant in context of question 1 and 2.
Thus, again nothing is currently migrated.
Via solving issue 122397 we can decide which extensions are migrated by 
using a white list and a black list.

Important note 1:
I have found code to migrate extensions - service But I currently do not know, if it 
works or not. But, I know that in the migration configuration data a 
white list and a black list for extensions can be specified.

Important note 2:
Regarding word lists or word books we currently have for the migration 
from OOo 2.x user profile to AOO 3.4.x/OOo 3.x a service named But I do not know, if it has something 
to do with word lists/word books.

> 4) What happens to the old AOO 3.4.1 install directories?  Is it
> removed?  Does that include extensions?  other files?  Is it totally
> clean?

As far as I had experienced - I need to double-check it -, during 
installation the user is asked, if the installation directory of a 
former found version should be removed or not. The extensions which are 
located inside the installation directory would be removed, too.
As far as I know the user profile of the former version will survive. 
This needs to be doubled-checked, too.

> 5) If extensions are not migrated, is there anything that helps the
> user to know what extensions they need to reinstall?  If not
> automated, maybe we need something in the Release Notes to explain how
> a user can make this list *before* they install AOO 4.0?

As far as I know, there exist no code to support the user in such a 

> 6) Does any of the above change if they are upgrading from AOO 3.4.0
> or OOo 3.3.0 or earlier to AOO 4.0?

Depending on what we decide for issue 122397.

Best regards, Oliver.

> 7) Once AOO 4.0 is installed, what happens if a user tries to install
> an extension that has not updated addons.xcu?  Is there an obvious
> error message, directing the user to contact the extension developers?
> 8) Same for incompatible C++ extensions.  Is the user given a
> meaningful message that directs them to the extension author?  Or will
> they be confused and end up asking us for help?
> 9) Is there any easy way users can tell which extensions on the
> Repository are compatible with AOO 4.0?
> 10) Are there any test extensions that QA can use to test the positive
> and negative cases of  #7 and #8 above?
> 11) Are there any other edge cases we need to think about?  Maybe
> future-proofing?  What happens to a future incompatible AOO 5.0
> extension when installed on AOO 4.0?
> I'm happy to update the Release Notes if the developers can clarify
> the expected behaviors here.
> Thanks!
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message