Difference between revisions of "Extensions releasing"
From Apache OpenOffice Wiki
(→Releasing) |
(→Requirements) |
||
| Line 5: | Line 5: | ||
== Requirements == | == Requirements == | ||
| − | * | + | * Extensions are a way to leverage the modularization of OpenOffice.org. To take advantage of this modularization the core OpenOffice.org build should be possible without the inclusion of extensions. |
| − | * | + | * 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 [http://external.openoffice.org/source/browse/external/exemptedextensions/ Exempted Extensions repository]). |
| − | * | + | * The release schedule of the extensions is independent from the OpenOffice.org release schedule. |
* To keep the release schedule of the extensions independent from the OpenOffice.org release schedule there should be an own 'target' in issuezilla and EIS. | * To keep the release schedule of the extensions independent from the OpenOffice.org release schedule there should be an own 'target' in issuezilla and EIS. | ||
| − | * | + | * For the development and release of C++ extensions there will be an WindowsIntel, MacOSXIntel, Solarisx86 and SolarisSparc, Linuxx86-32 and Linuxx86-64 environment should be available (other environments may be added). |
| − | * For every new release of OpenOffice.org all existing extensions | + | * For every new release of OpenOffice.org all existing extensions should get recompiled (and tested ?). A new extension will be build on the latest available OOo release even if a lower baseline can be used. |
| − | * | + | * The development and release of OpenOffice.org extensions should be leightweight and should encourage developers to contribute. Since the chance of breaking the vanilla OpenOffice.org build with an extension and in most case there is also no big development team involved 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). | ||
* Open: QA process and schedule | * Open: QA process and schedule | ||
| − | ** required: automated QA | + | ** required: automated QA (at least this is a requirement of Sun provided extensions) |
| − | * | + | * Localization process and schedule |
| + | ** Localization communities should be able to identify whether strings belong to the OpenOffice.org core product of to an extension to make the independent release schedule possible. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * Open: | + | * Open/TBD: Development Model |
| + | ** SCM - all extensions should be hosted in the extensions project (or http://external.openoffice.org/source/browse/external/exemptedextensions/) | ||
| + | ** Bugtracking - Target Milestones for an independent release schedule | ||
| + | ** Bugtracking - Component extensions plus subcomponent | ||
| + | ** Developing - branch/release model - choice of the developer | ||
Revision as of 09:39, 23 July 2008
Release builds of Extensions (Draft)
The release of OpenOffice.org extensions is done independently from the OpenOffice.org Release Schedule.
Requirements
- Extensions are a way to leverage the modularization of OpenOffice.org. To take advantage of this modularization the core OpenOffice.org build should be possible without the inclusion of extensions.
- 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).
- The release schedule of the extensions is independent from the OpenOffice.org release schedule.
- To keep the release schedule of the extensions independent from the OpenOffice.org release schedule there should be an own 'target' in issuezilla and EIS.
- For the development and release of C++ extensions there will be an WindowsIntel, MacOSXIntel, Solarisx86 and SolarisSparc, Linuxx86-32 and Linuxx86-64 environment should be available (other environments may be added).
- For every new release of OpenOffice.org all existing extensions should get recompiled (and tested ?). A new extension will be build on the latest available OOo release even if a lower baseline can be used.
- The development and release of OpenOffice.org extensions should be leightweight and should encourage developers to contribute. Since the chance of breaking the vanilla OpenOffice.org build with an extension and in most case there is also no big development team involved 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).
- Open: QA process and schedule
- required: automated QA (at least this is a requirement of Sun provided extensions)
- Localization process and schedule
- Localization communities should be able to identify whether strings belong to the OpenOffice.org core product of to an extension to make the independent release schedule possible.
- Open/TBD: Development Model
- SCM - all extensions should be hosted in the extensions project (or http://external.openoffice.org/source/browse/external/exemptedextensions/)
- Bugtracking - Target Milestones for an independent release schedule
- Bugtracking - Component extensions plus subcomponent
- Developing - branch/release model - choice of the developer
AI: list current extensions and their extensions.
- mediawiki
- presenter console
- templates, gallery
- presentation minimizer
- pdf import
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.
