From ADempiere ERP Wiki
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.
- There will be a quarterly "developer release" based on release branch. Naming convention: Something like AD2010.Q3, AD2010.Q4, AD2011.Q1, AD2011.Q2 etc.
- 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
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.
- 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)