Please Read!

Sahana is no longer working with CVS and Sourceforge.

Please see the relevant project's documentation: https://launchpad.net/sahana or visit Bazaar and Launchpad Instructions.

The Sahana release process is detailed below.

The picture above gives an example of how branching happens in the project. The terms are described below.

The terminology (e.g. alpha, beta, etc) is based on the following definition of the development stages in Wikipedia

• X Beta - The first release of version X that implements all the goals set for version X. This branch can become stable (X Stable)
• X Stable - The final relatively bug free release of X satisfying all the goals set for version X

Release Naming Convention

<Major Release Number>.<Branch Release Number>_[Beta|<Stable>_N][_<Deployment>]
      0.6             .2                      _Stable_2                         _RedCross

• Following will be used for the naming and tagging,
  • Branch/Tag : rel_<major_version_number>.<minor_version_number>
  • Deployment : dep_<major_version_number>.<minor_version_number>
  • Experimental : exp_<major_version_number>.<minor_version_number>

1. Only Bug fixes are allowed on Release and Snapshot Branches such that bugs always reduce with time on a branch
   • Justification: Ensure that the bug are always reducing on releases
2. Beta Release branches might become Stable if all QA checks validates it's readiness
   • Justification: Readiness is based on a quantitative analysis through the QA process
3. Releases will be made on a monthly basis off the latest release branch
   • Justification: Release incrementally, release often
4. Deployment branches are in branched off a stable or beta release and customization (enhancements) are allowed
   • Justification: Deployment requires a beta release at a minimum
5. Merge bug fixes in to BOTH the release and trunk at the same time
   • Justification: Propagate and don't lose Release Bug Fixes otherwise you will have to do it again in the next release

Example release tag naming with life cycle

Release Naming Convention :

• 0.6.3_Beta - Beta of the third release of 0.6
• 0.6.3_Stable - First Stable on third release of 0.6
• 0.6.3_Stable_2 - Second Stable on third release of 0.6

Note: A stable branch will be maintained until another branch gets 'stable' states.

Policy for the Sahana Q/A Testers :

• When bug is identified, it should be reported or tracked on the bug tracker on the SourceForge.net.
• Go through the bug tracker and make sure that the same bug is not submitted already.
• If the solution is a known one, then it can be attached (typically as a patch) to the same bug ticket as an attachment.

—-

Policy for the Sahana committors and other code contributors :

• Bug fixes are happened on the relevant release branches.
• Once read and understand the bug ticket, developer has to change the resolution of the ticket to relevant state. Also further comments can be added (by the developer) as and when needed.
• Once bug/s was fixed, developer has to make the ticket status to pending state and review team will review the ticket and assign the same bug to the main-trunk. Once main-trunk is fixed, again ticket status should be changed to pending and review team will review it once again. If both release branch and main-trunk were fixed then ticket will be closed and will be deleted later.

The branch used for GSoC has full write access for all students. This should be kept in-sync with trunk (as far as possible) by merging into the Branch.

This method was used unsuccesfully - all GSoC commits were lost.

('x' starts at '01' & gets incremented every sync)

cd sahana-phase2
cvs up -A
cvs rtag gsoc_2008_syncx .
cvs up -r rel_gsoc_2008
cvs tag gsoc_2008_pre_syncx
cvs update -j rel_gsoc_2008 -j gsoc_2008_syncx
[resolve conflicts - search output for 'conflicts']
cvs commit
cvs tag gsoc_2008_post_syncx