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

ERP 2.50:Release Timeline



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


So it is clear that releasing like a clock at the end 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


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 15th 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 15th 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 18th 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 15th pass all the tests. There is no guarantee that commits done between the 15th and the 18th get into the release.

So the QA process beings the 19th 00:00 (night between 18th and 19th). 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 22th till the 5th.

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 22nd of month A and it ends the 15th 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 3,038 times. This page was last modified on 14 June 2011, at 11:04. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.