2013/7/26 Hagar Delest <hagar.del...@laposte.net> > Top posting. > > Here we are. The first messages (ML and forum) about incompatibility are > coming. > The identified extensions (with toolbar and not updated for 4.0) should be > at least tagged in the extension site as not compatible with 4.0. >
This has been already done actually. To be more specific: A) a link to a version compatible with AOO 4.0 has been added for http://extensions.openoffice.org/en/project/pdfimport and http://extensions.openoffice.org/en/project/mysql_connector B) 4.0" has been added to the list of possible compatibilities. For example http://extensions.openoffice.org/en/node/287/releases doesn't enlist 4.0 among AOO compatible versions, while new extensions have that set, see for example http://extensions.openoffice.org/en/node/5644/releases. Note that it's up to the author to indicate his/her extension compatibility list, and he/she can update it without the need to upload the file again. Roberto > > A quick tutorial on how to update the extension in case authors want to > make the change urgently? > > Hagar > > > Le 13/02/2013 00:00, Rob Weir a écrit : > > On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest <hagar.del...@laposte.net> >> wrote: >> >>> Le 12/02/2013 13:05, Rob Weir a écrit : >>> >>> I don't know. I was asking a question. But I think this is an >>>> important question: Why would an extension author not update their >>>> extension for AOO 4.0? Some hypothetical answers: >>>> >>>> 1) The extension is unmaintained >>>> >>> >>> >>> One of the top reasons I guess. I myslef made extensions for my own use. >>> I >>> would have to tweak it. Since I've done them some time ago, I would have >>> to >>> dive again in specifications to make the changes. >>> >>> >>> >>> 2) The author cannot be located or we have no way to notify them of >>>> changes >>>> >>> >>> >>> May be related to 1). >>> >>> >>> >>> 3) It is not clear to the author what technical changes are needed >>>> >>> >>> >>> Was a communication plan issued to warn the authors about that? >>> Don't tell me the release notes are for that. Almost nobody read the >>> release >>> notes (at least until the end). >>> I guess that many extensions mlaintainers don't follow this dev list at >>> all. >>> >>> >> No, no. The Release Notes are just what I proposed to collect these >> kinds of items. If we actually make breaking changes I'd expect to >> see a bigger attempt to reach out to extension authors: >> >> 1) blog post >> >> 2) post to API list and forum >> >> 3) maybe banner on the extensions website itself >> >> But this would make more sense after the changes are made and when we >> can point to complete instructions as well as developer snaphot build >> that the author can use to test their modifications. >> >> What is not clear is how much notice is needed. 1 month? 2 months? >> More? >> >> -Rob >> >> >> >>> >>> 4) There is not sufficient calendar time for the extension author to >>>> make the needed changes before we release, or the work required is too >>>> much for the author to fit into his schedule >>>> >>> >>> >>> May be related to 3). Without any warning, few chances to implement any >>> change. >>> >>> >>> >>> 5) The author attempts changes but they don't work or they introduce >>>> new problems >>>> >>> >>> >>> Rather unlikely. >>> >>> >>> >>> 6) The results of not making the changes is not clear, so the author >>>> mistakenly thinks they are optional changes >>>> >>> >>> >>> Or he just don't care anymore about the extension. So it needs to be >>> taken >>> over by someone else. But how we could know that? >>> >>> >>> >>> 7) Author has technical or account issues with the extensions website >>>> and is unable to upload a new version, and does not know where to get >>>> help. >>>> >>>> These are all possible concerns, but I think most of them can be >>>> managed with good communications and advance notice. >>>> >>>> There is also the possibility of: >>>> >>>> 8) Inconvenience -- it is natural for anyone to complain about needing >>>> to do additional work where they don't see the advantage. So it is >>>> natural that we will expect complaints, followed in the end by >>>> conformance with the required changes. >>>> >>> >>> >>> Yes but what about the loss of confidence from users who will be first >>> frustrated by an upgrade that breaks more things than fix them? Then they >>> will have to do some homework to find out what the problem is (again, >>> don't >>> tell me about release notes). And wait in the end for someone to fix it. >>> What if they do need their extensions meanwhile? >>> >>> One side aspect: what about extension update warning? If a new version is >>> detected but the user doesn't upgrade to 4.0, are we sure that the >>> minimal >>> version will be checked first, before the new extension is installed by >>> the >>> user? Has he to download it before being warned that it's in fact not >>> compatible with his current AOO/OOo version? >>> >>> I'm not against the change. I'm for a controlled one, that has no impact >>> on >>> end-users. So the main points are: communication to the extensions >>> maintainers (what about the extensions hosted on their personal pages and >>> not on sourceforge?), preparation of the updates and transition period. >>> >>> Hagar >>> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
