Going forward, Openbravo intends to support the following product editions, based on the same source code tree:
- Community Edition
- Developer's Edition
The Community Edition's intent is to provide the community with a stable version of the product. Openbravo aims at publishing a new release of the Community Edition twice a year, approximately at six months intervals.
The strategic objectives are:
- To provide the community with a stable and well tested version suitable for production.
- To increase dissemination by providing, through an open source channel, a product that can be truly acquired and operated in a free manner.
Although the community edition is provided without warranty and with no support from Openbravo, this edition's QA process is open to the community. Each Community Edition, therefore, has received quality approval from both the Openbravo QA team and the community and it is suitable for production usage.
Additionally, user´s and implementation guides, as well as upgrade scripts, are available for the Community Edition.
Maintenance Policy for the Community Edition
Once released, defects can be reported against this edition but no guarantee is offered on when they will be fixed.
All bugs are fixed in the main repository. As a general rule the Mercurial commit messages contain the issue ID it fixes. As a general rule, bug fixes are only packaged as part of subsequent versions of the community edition.
That said, Openbravo is committed to having a stable and productive Community Edition and, at its own discretion, may release Maintenance Packs for existing releases before the next one is published.
Maintenance Packs are typically released early in the life cycle of a release, when the volume of bug inflow is historically higher. Once the release is considered stable, Maintenance Packs are no longer released and community members need to extract relevant bug fixes directly from the trunk.
The Developer's Edition is intended to provide the community with an up to date view into the latest software that has been updated by the development team.
It is essentially a snapshot of a release under development (nightly build).
The strategic objectives of this edition are:
- To increase dissemination by helping the community - especially developers- to try new features as soon as possible and in an easy way (reduce the time-to-user);
- To solicit help from the community with the testing process for ongoing developments.
The Developer's Edition is going to be published on a very frequent basis. Openbravo's goal is to publish it daily, but initially its frequency will depend on the level of automation that can be achieved in the build, QA and publish process.
Because of its frequency, the Developer's Edition is published with minimal QA process; no upgrade to or from a specific version of the Developer's Edition is provided.
The Developer's Edition is not suitable for production usage and the community is encouraged to download and evaluate it for testing purposes only.
Defects can be reported against this edition but no guarantee is offered on when they will be fixed. Bug fixes are only distributed as part of subsequent editions and never back ported to an existing Developer's Edition.
Openbravo intends to publish the first Developer's Edition in early 2008.
Understanding Version Numbers: the Life Cycle of a Community Edition
Openbravo releases are identified with a release number made of three numbers and a label, following the format x.yy.zzzz <label>, where:
- x is a single digit number indicating a technology generation;
- yy is a two digit number indicating a major release;
- zzzz is number that indicates the increasing level of maturity of the release and that matches to the SVN revision number corresponding to the release;
- <label> is a qualitative description of the maturity level of the release; it progresses as Developer Edition -> Alpha -> Beta -> Production -> Maintenance Pack 1 ->...-> Maintenance Pack n
An example of a release number is '2.40.1645 Developer's Edition'.
With this scheme:
- A change of first number indicates a significant change in technology
- In combination with the next two digits, it identifies a "series" or a release with a specific functional scope as it is normally perceived by the general public. Example: 2.40
A simplified example of the life cycle of two releases is in the following table:
|2.40 series||2.50 series|
|2.40.1628 Developer Edition|
|2.40.1632 Developer Edition|
|2.40.1648 Developer Edition|
|2.40.1649 Developer Edition|
|2.40.1672 Developer Edition|
|2.50.1678 Developer Edition|
|2.50.1690 Developer Edition|
|2.40.1720 Beta 1|
|2.50.1731 Developer Edition|
|2.50.1791 Developer Edition|
|2.50.1797 Developer Edition|
|2.40.1802 Maintenance Pack 1|
Further, in order to facilitate the community's understanding of the quality status of a release, we intend to:
- Clearly label each alpha and beta version with its status (alpha or beta).
- Include a statement in the release notes which clarifies the recommended usage of the release (testing or production).
- Keep the previous production release as the most prominent release in the Download page during the alpha and beta cycle.
Please notice that this release naming convention will take effect with 2.40 and has not been applied for 2.3x.
Updates allow users to upgrade from one release of Openbravo ERP to the next. Updates are published simultaneously when a new version is available.
The updates only update one version at the time. For example, if you are using Openbravo R2.33 and you want to update to Openbravo R2.35 you have first to run the updater from R2.33 to R2.34 and then run the updater from R2.34 to R2.35.