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
