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. 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 > > > > > > > >
