Difference between revisions of "Adempiere Release Management"
(→Basic principles) |
|||
| Line 18: | Line 18: | ||
* to provide place for QA | * to provide place for QA | ||
* to provide long lived place for bug fixes in the life of stable release branch. | * 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. | ||
| + | |||
| + | ====Release Tags==== | ||
Revision as of 03:11, 20 February 2008
Contents
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.
