Am Donnerstag, 17. Januar 2013 um 23:19 schrieb Rob Weir:
> On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt <jogischm...@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.
>  
>  

we will document it in the wiki with a detailed migration plan. Once we have 
this in place we will reach out to the extension developers. Release notes is 
one obvious thing but  a detailed blog post another one. We can ask Sourceforge 
to spread the new via the extension repo as well.  
>  
> How many month's notice would be enough? Can some update before a new
> release? Or would we need to provide a "beta" SDK?
>  
>  

we can start the communication asap when we have the docu in the wiki in place. 
We don't need necessarily a SDK for this. But the changed samples are part of 
the snapshot SDK.  

The change is really easy and no big thing.

I am planning a blog to talk about extension and the best way to maintain them 
over time.  

Juergen  
  
>  
> -Rob
>  
>  
> > Juergen  

Reply via email to