On 6/5/13 2:57 PM, Oliver-Rainer Wittmann wrote: > Hi, > > 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 > profile. > > 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 > com.sun.star.migration.Extensions. 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 > com.sun.star.migration.Wordbooks. 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 > scenario. > >> 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?
well Ariel can explain in detail what is implemented but as far as I know the user get no error message and the toolbar is simply not viewed. That was the reason why we recommend to use a max-version dependency in general. Even if API don't change, implementation changes can trigger a different behaviour and can result in not working extensions. I recommend to use a max-version dependency in general, do some QA for a new version and release a new micro release if necessary with an increased max-version. This is the only way to ensure that your extension works. >> >> 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? I am sure but I assume an error message that won't really help. To improve this a more complex rework and API changes would be necessary. It can be seen as a further design issue. >> >> 9) Is there any easy way users can tell which extensions on the >> Repository are compatible with AOO 4.0? no, I don't think so. It could help to check the min and max versions but I am not sure if this would be useful. >> >> 10) Are there any test extensions that QA can use to test the positive >> and negative cases of #7 and #8 above? we have test for extension but I don't know the current state. We have to check this and should include the tests in our automated tests >> >> 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? >> thinking about a new workflow and check of versions. Be more restrictive Juergen >> I'm happy to update the Release Notes if the developers can clarify >> the expected behaviors here. >> >> Thanks! >> >> -Rob >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
