On 1/17/13 3:00 PM, Bernard Marcelly wrote:
> Message de Jürgen Schmidt  date 2013-01-17 13:19 :
>> I disagree, the old mechanism is a design bug and should be resolved. It
>> was always planned to fix this a major release. Now with 4.0 we can make
>> such changes and we had long discussions about incompatible changes for
>> major releases. Extensions can be easy updated and by the way it is
>> always a good idea to add a max version dependency and release a new
>> version of your extension if you have ensured that it works with the
>> newest office version. How many unpublished API's are used in extensions
>> that can change at any time?
>> We probably don't have enough time to fix many more design bugs in the
>> API for 4.0 but this one is definitely worth the change. We will
>> document it and the fix is easy. But for all new extensions the usage is
>> much more intuitive and less error prone.
> The current mechanism is not a design bug (because it works), rather a
> clumsy design.
> To create a toolbar with the same name in Calc, Draw, Impress, you have to:
> - create one WindowState xcu file
> - make 2 copies of this file
> - modify one line in each copy
> - add entries for these files in the manifest.xml
> Is this really complex, error prone ? I don't think so, compared to all
> other features of an extension.
> About max version dependency : application developers don't see the
> future. It's not possible to know in advance when (and why) an extension
> will become incompatible.

exactly and that is the reason why I would today add a max version
dependency always. I know 4.0 will be next, I would change the max
version dependency to 4.0 after testing that everything works and would
do a micro release if I change nothing else.

> In the context of a company that has created a specific extension,
> happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
> Releasing a new version will be difficult: the original developer may
> have gone, or have forgotten the building details of an extension; a new
> developer has to learn the syntax of an oxt file, and find out what has
> to be changed to make it work again. Costs, delays. Benefits ? None.

This would be a situation that is always bad. If you use unmaintained
code you can run always in such trouble. In this specific case the oxt
can be changed easily and the Addon.xcu can be adapted, repackage the
oxt and that's it. No real code changes and you don't have to remove any
XXXWindowState.xcu if you have one.

I would love to have much more time to fix API design bugs or change
some bad API's to make the life for developers easier in the future. I
was a big fan of compatible API's but learned over time that good API's
have to evolve over time. We didn't do that and the API is often not
easy to use and to understand in many areas. We can improve a lot here
but probably not compatible. I have a mixed feeling about it but believe
that it will help us to make the product better over time.

This is an easy change, other API changes that require real code changes
will be more difficult to communicate.

As long as we communicate and document these kind of changes and provide
migration paths we are on a good way I think. We have to look forward.


Reply via email to