2013/5/7 Oliver-Rainer Wittmann <orwittm...@googlemail.com> > Hi, > > > On 07.05.2013 14:17, Oliver-Rainer Wittmann wrote: > >> Hi, >> >> On 07.05.2013 09:30, Shenfeng Liu wrote: >> >>> 2013/5/7 Rob Weir <robw...@apache.org> >>> >>> On Mon, May 6, 2013 at 1:58 PM, janI <j...@apache.org> wrote: >>>> >>>>> On 6 May 2013 19:37, Rob Weir <robw...@apache.org> wrote: >>>>> >>>>> On Mon, May 6, 2013 at 1:25 PM, janI <j...@apache.org> wrote: >>>>>> >>>>>>> On 6 May 2013 18:27, Rob Weir <robw...@apache.org> wrote: >>>>>>> >>>>>>> What do we need to do to test AOO 4.0 -> AOO 4.1 upgrade scenario? >>>>>>>> >>>>>>>> >>>>>>> Do we already have documented procedures for the AOO 3.4.1 -> AOO 4.0 >>>>>>> upgrade ? >>>>>>> (searching in wiki for "4.0 upgrade" gives no result) >>>>>>> >>>>>>> If not I would suggest we make the documentation and test plan for >>>>>>> the >>>>>>> 3.4.1 -> 4.0 before thinking about the next upgrade. >>>>>>> >>>>>>> One thing that really needs to be tested is a 3.4.1 danish (example) >>>>>>> installation, upgrade to a 4.0 english installation. At this point in >>>>>>> >>>>>> time >>>>>> >>>>>>> I foresee a 4.0 release with less languages than 3.4.1 (with language >>>>>>> respin). The tests should include fallback scenarios for users who >>>>>>> >>>>>> want >>>> >>>>> to >>>>>> >>>>>>> stay with their language version. >>>>>>> >>>>>>> >>>>>> Two different things: >>>>>> >>>>>> 1) The upgrade notifications. This is triggered by an XML file we put >>>>>> on our website that the client checks, by default once a week. For >>>>>> example, here is one of the existing update notification files: >>>>>> >>>>>> >>>>>> >>>>>> http://www.openoffice.org/**projects/update38/** >>>> ProductUpdateService/check.**Update<http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update> >>>> >>>> >>>>>> >>>>> ok my mistake, but I still think we should discuss this for 4.0 and not >>>>> >>>> 4.1. >>>> >>>>> >>>>> >>>> Let me be explicit. We need to test AOO 4.0's ability to be correctly >>>> process notifications about the existence of AOO 4.1. And we need to >>>> do that now, since after AOO 4.0 is installed on user's machines it is >>>> too late to fix any client-side bugs in this area. >>>> >>>> Some may remember, for example, a bug in AOO 3.4.0 where such >>>> notifications were disabled by default. And with 3.4.1 we had a bug >>>> where in some cases clients crashed when checking for extension >>>> updates. >>>> >>>> >> The defect we had in AOO 3.4 and AOO 3.4.1 regarding the update >> functionality - as far as I know - was the following: >> - If the user had upgraded an OOo 3.3 installation with AOO 3.4 or AOO >> 3.4.1 the bundled extensions delivered with OOo 3.3 were deleted from >> the installation, but the extension database still contains the >> corresponding entries. During automatically triggered update check for >> the application also an update check for the extensions is triggered. >> Due to the inconsistent extension database the deleted bundled >> extensions were tried to access. This causes an C++ exception which was >> not caught and caused a crash. This is fixed for AOO 4.0. >> >> So we do need to worry about AOO 4.1 now, at least to the extent AOO >>>> 4.0 needs support in its code to handle notifications about 4.1. >>>> >>>> >>>> Rob, >>> So my understanding for the purpose of this discussion thread is >>> that we >>> need to test the upgrade notice in AOO 4.0, and ensure it can work when >>> future releases (e.g. 4.1, 4.2...) available. Then I totally agree >>> that it >>> is very important and we need to add it to our test plan. >>> While I want to confirm some technical details (and some of my >>> understanding below is from my reading of the URL you provided above): >>> >>> 1. Is the URL unique for each release? And this URL will work for all the >>> platforms and languages packages for this release? >>> >> >> The URL to check for application updates is unique for each release. At >> least this is the case for the former releases and it will be for AOO 4.0. >> It work for all platforms and languages. >> The URL for AOO 4.0 will be >> https://ooo-site.apache.org/**projects/update/aoo40/check.**Update<https://ooo-site.apache.org/projects/update/aoo40/check.Update> >> Have a look at main/instsetoo_native/util/**openoffice.lst and search for >> string "UPDATEURL" >> >> 2. Is the upgrade notice only for release upgrade purpose, but not >>> promotion of extensions or templates? >>> >> >> OpenOffice contains two update functions. One for the application update >> and one for the extensions updates. >> The update check for the extensions is automatically triggered (if >> configured) at the same interval as the update check for the applications. >> Each extension can provide its own URL for the update check, but there >> is a fallback (URL currently not known to me). >> > > It is http://updateexte.services.**openoffice.org/** > ExtensionUpdateService/check.**Update<http://updateexte.services.openoffice.org/ExtensionUpdateService/check.Update>- > found in main/scp2/source/ooo/common_ > **brand.scp > But currently no update feeds are provided. >
The upcoming AOOE website will manage Extensions' updates. Roberto > > Best regards, Oliver. > > > >> 3. For (A) and (B) below, I suppose they are not in AOO 4.0 scope, right? >>> 4. For the testing perspective, can the URL be customized in AOO build >>> ? If >>> yes, we may create a fake URL for development/testing purpose, without >>> impacting external users. >>> >> >> Yes, the URL can be changed - even when AOO is running. >> Search for file "version.ini" (Windows) resp. "versionrc" (other >> platforms) in your installation. It contains an entry starting with >> string "UpdateURL=". You can simply change its value to another URL. You >> can also use a "file://" URL to a file on your local file system. >> >> >> Our wiki page [1] provides detailed information about the application >> update functionality in OpenOffice. >> >> >>> - Shenfeng (Simon) >>> >>> >>> >>> >>>> >>>>>> There is a different base URL for each version, pointing to a file >>>>>> like this that lists the available upgrades for that version. >>>>>> >>>>>> Since the update checking code has changed, we should make sure we >>>>>> have good testing on that, on all platforms. There was also talk of >>>>>> making that update check occur over SSL. That could be done by: >>>>>> >>>>>> A) Getting an SSL certification for *.openoffice.org or for the >>>>>> specific subdomains of interest >>>>>> >>>>>> or >>>>>> >>>>>> B) Moving the update notification files over to openoffice.apache.org >>>>>> , >>>>>> where we can presumably just use the existing Apache certificate >>>>>> >>>>>> >> I changed the UpdateURL for AOO 4.0 to >> "https://ooo-site.apache.org/.**.<https://ooo-site.apache.org/..> >> ." >> to benefit from the existing Apache certificate. >> >> However we do it, we need code changes in 4.0 to accommodate this, and >>>>>> testing as well. >>>>>> >>>>>> >> There are no code changes for AOO 4.0. As far as I know there are also >> no changes planned. >> >> >>>>> that is correct. >>>>> >>>>> 2) The actually install of 4.0 over AOO 3.4.1. My impression was that >>>>> >>>>>> major upgrades like this installed into a new directory and there was >>>>>> no automatic migration of settings. If so the testing side of it >>>>>> would not be difficult. Same for reinstalling 3.4.1 over a 4.0 >>>>>> installation. Different directories, so no conflict. >>>>>> >>>>>> >> Yes, AOO 4.0 will be installed in a different directory. Also the user >> profile will be located i a different directory. >> As far as I remember it correct from my testing on Windows a couple of >> month ago, the user is asked during the installation, if a former >> version should be removed or not. >> >> >>>>> Well, I am not the best example, but the 3.4.1 danish spreadsheet, did >>>>> >>>> not >>>> >>>>> like 4.0 english version, until I saved them in 4.0. >>>>> >>>>> >> This sounds like a defect. >> If possible, please submit an issue in Bugzilla for specific information >> and if available corresponding sample documents. >> >> I am not sure if the problem is of general nature (danish->english) and >>>>> roots in the document itself. >>>>> >>>>> And if installing in different directories, we need to help the user >>>>> >>>> with a >>>> >>>>> cleanup possibility. >>>>> >>>>> >>>> All good scenarios to test. >>>> >>>> -Rob >>>> >>>> >>>> rgds >>>>> jan I. >>>>> >>>>> >>>>>> -Rob >>>>>> >>>>>> >>>>>> +1 to testing the upgrade scenarios. >>>>>>> >>>>>>> >> +1000 for testing upgrade scenarios. >> I assume that the QA people have such testing already in mind. >> >> rgds >>>>>>> jan I. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Is it possible to put an update XML file on the server so we can >>>>>>>> trigger update checks, etc., to verify that this is working? >>>>>>>> >>>>>>>> As we know, we had some update checking crashes in AOO 3.4.1, so we >>>>>>>> really should try to get some test coverage of both positive and >>>>>>>> negative checks. Maybe one locale (English) we say there is an >>>>>>>> update, and in another locale (German) we say there is no update, so >>>>>>>> we can exercise both paths? >>>>>>>> >>>>>>>> Of course, we would then need to remove the test file from the web >>>>>>>> server before we ship. >>>>>>>> >>>>>>>> -Rob >>>>>>>> >>>>>>>> >> >> [1] >> http://wiki.openoffice.org/**wiki/Update_Notification_**Protocol<http://wiki.openoffice.org/wiki/Update_Notification_Protocol> >> >> >> Best regards, Oliver. >> > >
