Difference between revisions of "Working Procedures"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
(Made page obsolete.)
 
Line 1: Line 1:
{{Obsolete|Please see the [[Software Development Procedures]] instead.}}
+
{{Obsolete|Please see the [[Software Development Procedure]] instead.}}
  
 
{{Template:Draft_proposal}}
 
{{Template:Draft_proposal}}

Latest revision as of 22:46, 1 November 2015

Caution.gif This page is obsolete.

Use the information here with caution. Please see the Software Development Procedure instead.

Purple question mark The following is a working draft of a proposed ADempiere policy, guideline or process.
The proposal is definitely still in development and under discussion, and has not yet reached the process of gathering consensus for adoption. Thus references or links to this page should not describe it as "policy" nor yet even as a proposal.

This is an initial draft of ADempiere Project Working Procedures for developers and citizens. They should serve as a guideline on how to achieve the common goal of a high quality Open Source ERP System.

This is a working document which should be extended as needed.



Developer Releases

  • There will be a quarterly "developer release" based on release branch. Naming convention: Something like AD2010.Q3, AD2010.Q4, AD2011.Q1, AD2011.Q2 etc.

"Official Releases"

  • Announcement of a new "official release" will be provided when PMC thinks, AD is ready for a new release for common usage. Such release always will be based on current developer release (i.e. not necessarily identical with)

Development on trunk

is divided into several time windows:

  • Extension period: Starting from time of quarterly developer release for a period of 6 weeks, new developments (either small from local repositories or matured in branches) can be integrated into trunk.
  • Stabilization period: After extension period, concentration on bug fixing, stabilization, cleanup, etc. No "big commits", minor additions allowed.
  • Frozen/Release period: No changes except for bugfixing, release naming until quarterly developer release is out.

Development in release branch

in these time windows:

  • Extension period: Only bug fixing and minor changes on release branch
  • Stabilization period: Promotion of stuff from trunk to release as they seem mature enough
  • Frozen/Release period: Bugfixing, cleanup for release, tagging release, etc.

Commit and reversion rules (on trunk)

  • During extension period, developers may commit to trunk
  • During stabilization period, developers may commit bugfixes, optimizations, "housekeeping" (renaming of variables, etc.), minor additions, etc. (needs more elaboration)
  • If a commit breaks something (trunk does not compile, regression test fails, etc. There has to be a documented test case!), developer has from one day (case: trunk does not compile) up to one week (in less critical situations, needs more elaboration) to fix it, otherwise it will be reverted

Maturity

Things may not end up in release, even if they were in trunk. PMC should provide advice and maybe coaching in these situations on how to go forward. Possible sokution: Move things (back) to branch to mature.

Roles

  • PMC has responsibility to make these rules work.
  • PMC defines trunk maintainers (at least two, no single point of failure!) who have the right to revert according to above rules
  • PMC defines release maintainers (at least two, no single point of failure!) who decide on promotion of things from trunk to release
  • Release maintainer and trunk maintainer must not be identical (mutually exclusive roles!)
  • Developer needs "right" to commit to trunk.
  • "Everybody" can be branch developer on his own branch. A branch needs to have two branch maintainers (no single point of failure)