On Wed, Jun 5, 2013 at 9:16 AM, Jürgen Schmidt <jogischm...@gmail.com> wrote: > 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 >
The most common use case here will probably be dictionaries packaged as extensions. There are many more languages supported via dictionaries than we have UI translations, right? As we saw with the 3.4.1 upgrade, profile issues caused users to lose access to their dictionaries. This caused a lot of confusion, bad word-of-mouth on social media, many duplicate BZ issues, posts on user list and forums, etc. So if there is something that we can do to improve the user experience here, let's try. If users lose their dictionary access, without advance warning or useful error message then we'll just get a repeat of what occurred with 3.4.1. At the very least we can put something into the Release Notes, but I assume only a minority would read them... Is there any facility in the upgrade wizard to put some additional text, to warn the user of what will happen and what they need to do, so we can avoid problems? For example, what if we had a link to a web page or wiki page where we explain? For example, the upgrade dialog could say: "You currently have 3 extensions installed (A, B and C). These will need to be reinstalled after the upgrade completes. Most extensions are available from http://extensions.openoffice.org. More information is here..." -Rob > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
