Difference between revisions of "Adempiere Release Management"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
Line 28: Line 28:
 
as they do not work and can cause problems with too adventures end users.
 
as they do not work and can cause problems with too adventures end users.
  
====Release Tags====
+
 
 +
====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.

Revision as of 03:16, 20 February 2008

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.