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.
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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
