Adempiere Release Management
Some basic rules of release management in Adempiere project as of 3.4.x releases
History
In the start of Adempiere, developers agreed that release should be done based on functionality and that Trunk version in SVN should be kept "production stable" at all times.
While this model is nice to developers it is quite troublesome for implementors, as they don't have long term production ready releases with enough bug fixes.
So some of us proposed new so called time based release management strategy and been given green light to go with it for upcoming 3.4.x releases.
Basic principles
Release Branch
For time based release management basic principle is, that at some point in time we decide and make so called Release Branch. This release branch is spin off of main development which is happening in trunk.
Release branch main goals are:
- to provide place for stabilization
- to provide place for QA
- to provide long lived place for bug fixes in the life of stable release branch.
After creating stable branch some activites are necessary on the path to stable release:
- stabilization of the code in form of BUG fixes (Bug Days)
- QA testing in form of real or simulated implementation
- disabling of not functional parts of code/AD
This period should not be too long, as current trunk seems to be quite stable. However there are some areas of new functionalities that should be either disabled or fixed before first stable release (tag), as they do not work and can cause problems with too adventures end users.
Stable Release Tags
Stable releases are based on stable branch. At some point in time, when most of bugs and QA have been done we should make stable release.
Stable releases are technically tags in which NOBODY should commit. So they are snapshot of code at given time.
All bug fixes are still maintained via Stable Branch.
First stable release should be done for example 7-14 days after creation of stable branch, with preferably at least one Bug Day in that period.
Operative example of Release Branch (3.4)
On Wednesday 20.02.2008 we are opening release branch:
branches/adempiere34
Please be advised, that branches should never have release numbers like 340, 341, and so on. We have only one stable branch 3.4 for all 3.4.x releases.
This branch is effectively copy of trunk at that point of time.
Now we are in the point of stabilization and QA before actual first release.
What should developers do first
At that time, developers should first create necessary adjustment to code, that would allow users to install from scratch:
- Prepare and commit databases DUMPs - only this is acctualy mandatory
- Change information about code release to adempiere_3.4.0 <- Here we already prepare for the first release
- ?
This should be done as soon as possible as QA testers usually are not enough skilled with the code and we surely want to attract as many testers as we can.
Once we have those basics set, QA testers can start their job finding bugs and not worked functionality.
What should QA testers do
QA testers should now check out this stable branch branches/adempiere34 and make their installation based on this code base.
- Every bug should be reported to sf.net bug tracker and marked as 3.4 bug
- Every not working functionality should be reported to sf.net bug tracker also
- Report success with new functionality on the forum ?
First Stable Release of Stable Branch
After at least basic QA testing and bug fixing, we should make first stable release.
In our case this would be Release: tags/adempiere340 (Adempiere 3.4.0)
If we are lucky and no DB changes were neccessary (not likely) we can just copy current 3.4 branch to release tag and be over, but this is unlikely.
So before making releases developers should prepare Databases dumps.
