Extensions releasing

Release builds of Extensions (Draft)

High-level requirements

Extensions are a way to leverage the modularization of OpenOffice.org. The code of Extensions and the core OpenOffice.org needs to be separated to decouple the code and to allow less prerequisites for Extension building. Ideally, at least for Java extensions, all that is necessary to create and/or build an Extension is the OpenOffice.org SDK, a JDK and perhaps one or two small tools. This lowers the hurdles for new contributors to start developing for OpenOffice.org.

The release of OpenOffice.org Extensions is done independently from the OpenOffice.org Release Schedule.

Localization communities need to be able to identify whether strings belong to the OpenOffice.org core product or to an Extension to make the independent release schedule possible.

Consequences

• To take advantage of the modularization introduced with Extensions, the core OpenOffice.org build should be possible without having to build extensions and of course vice versa.

• To keep the release schedule of the extensions independent from the OpenOffice.org release schedule there should be own 'targets' in IssueZilla and EIS.

• For the development and release of C++ Extensions, environments for Windows, MacOS X (Intel), Solaris x86 and Solaris Sparc, Linux x86-32 and Linux x86-64 should be available (other environments may be added).

• The development and release of OpenOffice.org extensions should be lightweight and should encourage developers to contribute since the chance of breaking the vanilla OpenOffice.org build with an extension is not likely. In most case there is also no big development team involved. So it should be possible for contributors to choose the development process of their own choice. The contributor of an extension is able to have full control about the release process (development, qa, release).

• To enable localization communities to identify whether strings belong to the OpenOffice.org core product or to an Extension, the code and translatable strings of Extensions should be placed in separate modules. String changes in these modules indicate translations for Extensions need to be done, strings changes in other modules indicate translation work for the core OpenOffice.org product.

• Automated QA must be possible for Extensions (at least this is a requirement of Sun provided extensions).

• The build system for Extensions should be the same as for the core OpenOffice.org.

Recommendations

• It is recommended to develop extensions in Java or other platform independent supported language so that the resulting extensions are able to run on every supported platform.

• Extensions should be buildable by an automated build service to encourage contributions of Extensions into OpenOffice.org repository (also non SCA'd contribution hosted on Exempted Extensions repository).

• For every new release of OpenOffice.org all existing extensions should get tested (recompile is not necessary, since API's are stable). A new extension will be build on the latest available OOo release even if a lower baseline can be used.

ToDos

• SCM - where to host extensions? For non-SCA'd ones something like the Exempted Extensions repository, those contributed under SCA can be hosted next to OpenOffice.org source code.
• Bugtracking
  • Target Milestones for an independent release schedule
  • Component extensions plus subcomponent
• Developing - branch/release model - choice of the developer?
• Code required for localization, e.g. the module transex3 and modules it depends on, needs to be moved to the SDK.

Releasing

• Extensions/website/submission
• A list current extensions and their extensions is available at Extensions_Overview