openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juergen Schmidt <jogischm...@gmail.com>
Subject Re: Incompatible change for extensions
Date Fri, 18 Jan 2013 06:18:28 GMT
Am Freitag, 18. Januar 2013 um 04:26 schrieb Carl Marcum:
> 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?
>  
>  

yes the generated Addon.xcu has to be adapted.
>  
> If so where could I find the information needed?
see the issue above or take a look in the examples. It's no big thing

 Juergen
>  
> Thanks,
> Carl
>  
>  



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message