openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Marcum <cmar...@apache.org>
Subject Re: Incompatible change for extensions
Date Fri, 18 Jan 2013 03:26:34 GMT
On 01/17/2013 05:19 PM, Rob Weir wrote:
> On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
>> 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.
>>
>
> So speaking of communications...  What's the plan?
>
> If we're really going to make incompatible changes, we should probably
> do more than put it in release notes or Bugzilla.  It should probably
> go into a blog post, with advance notice and a link to technical
> details.
>
> How many month's notice would be enough?  Can some update before a new
> release?  Or would we need to provide a "beta" SDK?
>
> -Rob
>
>
>> Juergen
>>
>>
>>
>>
>>
>>
>>
>>
>

Will this effect tools like the Netbeans plugin that would need updated 
or modified to create a new extension compatible with 4.0?

If so where could I find the information needed?

Thanks,
Carl

Mime
View raw message