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
