Adempiere Release Management

From ADempiere
Revision as of 04:36, 20 February 2008 by Gody01 (Talk) (Release Management Illustration)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

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:

  1. Prepare and commit databases DUMPs <- only this is acctualy mandatory
  2. Change information about code release to adempiere_3.4.0 <- Here we already prepare for the first release
  3.  ?

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.

Consecutive operations on Stable Branch

After first stable release, users will still found bugs in day to day operations.

Such bugs have to be resolved in stable branch and as soon as possible transfered also to trunk.

Procedure for developers is as follows:

  1. check out from stable branch branches/adempiere34
  2. Create installation (best way with alternative (DB/DBusername)
  3. Replicate bug
  4. Fix bug
  5. Commit to stable branch
  6. Document

After fixing bug, developer can go back to do development on trunk version.

When enough bug fixes is collected, there is a time for new stable release. Once again developers should prepare database DUMPs and release number corrections and stable branch can be copied to stable release/tag: tags/adempiere431

This cycle is repeated, until there are production use and bug fixes for this stable branch.

Stable branch commit rules

For time being I would like to ask, that only bug fixes are made on stable branch. All new functionalities should be made in trunk. If we can achieve the goal of often releases there will be no need to put any functionality and enhancement into stable branches.

In the long run however, there can be change in this policy, if we fail to release often enough. Than some minor enhancement could be aplied to stable branches as well.

Release Management Illustration

Since one picture can replace 1000 words:

Adempiere release management.png

Explanation:

  1. Trunk is main development pool, here all normal development takes place
  2. At some point in time we split Stable Branch for preparation of stable release
  3. RED part is for developers, to prepare DB seeds, release names, etc ...
  4. YELLOW part is QA testing/bug fixes time in preparation of first stable release
  5. GREEN line is Stable Release time (e.g.: tags/adempiere340)
  6. DARK GREEN is normal production use and bug fixes as they shows up
  7. second GREEN line is next Stable Release time, when enough bug fixes are collected that it makes sense.
  8. Experimental BRANCH is for experimental development. It my or may not be actually valid or useful, so we make specail branch. But eventually any experimental branch should be either discarded or included into trunk. If not we have a fork !