Release Timeline
Contents |
Introduction
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.
Goals
- The main goal is to release a Openbravo ERP 3.0 minor version at the 15th of every month (aka maintenance pack).
- Developers should know what commits they push go into what release. This way they can organize their work more efficiently.
- The QA team should know the exact dates in which the QA starts and the project merges happen.
- The Release Management team should know the exact dates in which to freeze and release.
- The Support team should know the exact date ranges in which their issues will get into which release. And these ranges need to comply with the SLAs.
- Users and customers like to know the exact release dates, e.g. at the end of every month.
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:
- Test: primarily used by the Openbravo QA team. This is the pre-release status.
- Controlled release: it means they have passed the automated tests, the issues have been individually verified and the QA team has run a comprehensive set of manual tests.
- General availability: the module has passed 40 days in the Controlled release maturity level without any known issues.
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:
- Every row represents a month.
- The only exceptions are 2.50MP22 and 2.50MP23, that were released the same month.
- The RC template versions are released every 2 months.
- The Template label column represents the LABEL field of that module. And for the sake of clarity the second column displays the major version plus the LABEL field of the Core module.
- 2.50MP24 is the last 2.50 Core which is used for 3.0 (3.0RC3). Starting from that 3.0 release there's no equivalence between the 3.0 and 2.50 Cores. Hence the n/a text indicates this unavailability.
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
Developers
- 4th of month A till 1st of month B: Developers do commits into /erp/devel/pi. All these commits will go into the month B release.
- 8th of month A till 24th of month B: Developers reintegrate some projects into erp/devel/pi. All these projects will go into the month B release.
- 1st of month A till 4th of month A: Developers do commits into /erp/devel/pi. All these commits are not guaranteed to go into the month A release. It depends if they changesets of pi pass the tests.
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.
FAQ
- There are some months like May 2010 were the 1st is Saturday and the 4th Tuesday. What happens in those cases?
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.