View source | Discuss this page | Page history | Printable version   

Release Timeline



This document describes the different phases of the release engineering process leading up to the actual build and publication of a 3.0 maintenance pack.


So it is clear that releasing like a clock at the middle of every month is beneficial for all the parties. Now we will see what we need to do to coordinate all the teams in this effort.

These policies are a result of discussing the topic with developers, the QA Team, the Support Team and Engineering managers.

Scheduling overview


Maturity Levels

This major version of Openbravo will make use of the maturity levels concept since the beginning. This feature allows Openbravo to make use of its statuses as follows:

So taking the maturity levels into account the release timeline graph gets transformed as follows:


Version naming rules

Version 3.0 consists of a distribution of modules, being Core and the Template the most significant ones. This section describes the module version naming rules to be applied in these two modules.

The code of Core has been shared with version 2.50 until version 2.50MP24. So the version naming rules will be as follows:

Template label Core (major version + label) 2.50 Core equivalence
RC1 - 2.50MP19
- - 2.50MP20
RC2 3.0RC2 2.50MP21
- 3.0RC2 2.50MP22
- 3.0RC2 2.50MP23
RC3 3.0RC3 2.50MP24
RC4 2.50RC4-A n/a
- 2.50RC4-B n/a
MP0 3.0MP0 n/a
MP1 3.0MP1 n/a
MP2 3.0MP2 n/a

These points should serve a a guide to interpret the table:

Note that although 3.0MP0 will be the first General Availability version of 3.0, commercially we will refer to it as 3.0.

Developers: commit guarantee threshold

So the first thing we need to do is to put it clear for the developers which of their commits will go into which release. When they can perform project reintegrations. To sum up, how they should organize their teams and their time.

As a first policy, every push done to erp/devel/pi until the 1st of every month will be guaranteed to go into the release. The Release Management team will work together with the developers to guarantee this. If all the tests pass the 1st then the RM team will do nothing. But if some tests do not pass then RM will work closely with the developer to fix the issue. If it's not solved within 12 hours then the commit will be backed out.

The freeze will happen the 4th of every month, taking the code available in erp/devel/main. So that the RM team and the developers will have 3 days to get all the commits from the 1st pass all the tests. There is no guarantee that commits done between the 1st and the 4th get into the release.

So the QA process beings the 5th 00:00 (night between 4th and 5th). And it finishes at the end of the month.

Developers: projects reintegrations into erp/devel/pi

Project reintegrations are prone to cause more issues than when there are no reintegrations. As a consequence these merges will be done in a specific date range: from the 8th till the 24th.

Developers should merge from erp/devel/pi into their branches very often (1-2 days) for their own good. But the reintegrations into erp/devel/pi must be done within this range.

Example by roles


So from a developer's point of view the release process starts the 8th of month A and it ends the 1st of month B.


We believe that having fixed dates has more benefits than drawbacks. Variable dates depending on vacation days are difficult to remember and this is why we have avoided them. In principle the days will be taken strictly. But of course we are not machines and we will act with common sense. So as a general rules the dates with be taken as explained, and exceptions will be studied individually.

Retrieved from ""

This page has been accessed 4,541 times. This page was last modified on 14 June 2011, at 17:39. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.