Software Development Procedure

This Wiki is read-only for reference purposes to avoid broken links.

STATUS: This concept is under work.

This is a suggestion to replace the PMC Head Concept (http://www.adempiere.com/index.php/PMC_Head_Concept).

What are the goals of this document

The reason is that this concept defines the procedures in order to fillfil the following goals:

• produce high quality ERP software
• regular and plannable releases
• an all time stable trunk
• clear rules how to get code into trunk
• have several features under development at the same time
• documentation for new features
• teams are to be responsible not single persons
• lean project layout

You see, there are a lot of goals that need some structure around it to make the real.

The concept in a Nutshell

• instead of committing to trunk and having a guarding watching the changes we switch to a process where features need to be approved until they are comitted
  • the responsibility is to the developer and not the release manager to ensure high quality
• instead of having a single person being resonsible for everything (PMC Head) we rely on teams being self responsible

Software Production Cycle

Development Phase (3 Months)

• A stabilization branch is created from trunk which is the main line of development.
• new functionalities are implemented in seperate development branches with the aim to get them into stabilization branch
  • Developers have 3 months time for integrating new functionalities, changes, Bug fixing and Integration testing in their branch
  • Before integrating new/ changed Funtionality in "stabilization" the Developers/ Implementors have to apply for approval by Technical and Functional Team

Stabilization Phase (1 month)

• After development phase is over there is 1 month stabilization phase where the stabilization branch is frozen for new features. In this time only Bugfixing and User Acceptance Tests (UAT) are allowed.

Release

• stabilzation branch is reintegrated into main line of development and a release is done (svn tag).
• The next stabilization branch cycle starts. The old branch is deleted. The new one is again created from main line of development trunk.

Developer working in Development Branch

Process

• Every Developer can open an own experimental or feature development branch. The branch can be taken from trunk or "stabilization". The developer who opened the branch is the maintainer of the branch.
• The Maintainer can prepare the reintegration of his branch into "stabilization" branch by informing Release Manager, Technical and Functional teams. This shall be done as early as possible, so that Release Manager can oversee the complexity of new Implementations and can give early consultancy about when to integrate.
• Once the maintainer gets the approval of Technical and functional team he can merge his branch into stabilization branch
• after integration into "stabilization" Integration testing is performed

Rules

• Development of new functionality happens only in development branches.
• For each branch there should be a
  • forum post anouncing the development in forum
  • wiki page
  • feature request in tracker
  • entry in feature development collaboration wiki page
• ANY code that is committed to any official branch (including trunk) should respect a set of rules:
  • 100% compliance with Adempiere Best Practices (ABP)
  • code is formated using the official formatting definition (need to be defined and agreed on, but in meantime you can take this as an example)
  • respect Subversion Best Practices (see [1])
• The Maintainer is responsible to keep his branch up-to-date with stabilization branch and therefore must merge hotfixes into his branch.
• The Maintainer decides who has the permission to commit into his branch.
• Any data model change should be announced, discussed and voted (example: the placed were we store some well known informations like contact phone changed)
• Master Data Models (organizations, bpartners, contacts, warehouses etc) should be consistent and is not allowed to have different ways of defining the relations between this entities (examples: storing the organization details like addresses, phones, faxes in Organization Info tab or in the linked business partner)
• in case of complex functionalities, ADempiere Generic Workflows should be defined in order to guide the user how to setup the functionality and which is the designed the business process (example: take a look at Manufacturing Management Setup workflow from your ADempiere main menu)
• The maintainer is responsible to provide immediate effort if the integration harms the "stabilization" branch.
• "Dead" or "unmaintained" branches shall be avoided

Technical Team

• technical team is responsible to provide a release manager amongst their members

Process

• When a feature in a development branch is ready for approval the developer contacts the technical team and applies for approval
• Technical Team meets on a regular basis and discusses the applications
• If all criteria are met the team approves the feature from a technical perspective and allows the developer to merge his feature into stabilization branch

Rules

• Any code structural change (e.g. file/ directory rename/ move/ delete) should be announced and approved by Technical team before applying it.
• The Technical team approves / rejects the integration of code or any other change into "stabilization"
• The Technical Team checks if
  • is code documented
  • backward compatibility is achieved
  • migration scripts complete
  • technical documentation sufficient
  • backward comparability analysis
  • migration scripts are provided (when needed)

Initial Staff

• Teo Sarca
• Karsten Thiemann
• Tobias Schöneberg
•  ???

Release Manager

Process

• creates stabilization from trunk when new development cycle begins
• produces a release from stabilization branch after stabilization phase

Initial Staff

• To be defined

Functional team

Process

Any functional change from ADempiere default should be announced and approved by Functional Team before applying it (examples: documents behavior changed from standard, processes behavior changed from default, main menu items moved from their default location, fields of a standard window were reorganized etc.).

• After the technical team has approved
• The Functional team has got the final decision on which feature is accepted. The Functional team approves or rejects an Integration into stabilization branch from a functional perspective.

Rules

• The Functional team checks checks if
  • requirement makes sense
  • requirement is solved
  • test cases are complete and meet the requirement
  • user documentation sufficient
  • the ADempiere Wiki-Page describing this functionality contains
    • requirement specification
    • test cases
    • test documentation (how tested which test cases with which results)
    • user documentation

Initial Staff

• Ramiro Vergara
• Mario Calderon
• Norbert Wessel
• Mark Ostermann

Other teams

There are already other teams that could be integrated into this Integration Process where it makes sense. For example Usability, Security team.

Reverting policy

• technical team has the responsibility to revert code that is not compliance with our rules set (technical, functional).
• The revert should be motivated precisely and without any doubt.
• Any other person outside of the technical team (including the functional team) are not allowed to revert, but are advised to call for a revert where they specify the concrete reasons.
• In case there is a contribution that based on strong reasons is not well done, but is respecting the "SVN Procedure", we can call for a community process to modify the "SVN Procedure" and to enforce this rule from now on.

Ideas behind the concept

• It will be nice to already have a Roadmap for the different stabilzation cycles, but it is not a must (new functionalities, changes can be announced by Developers in advance and are the put into the roadmap for stabilzation cycle).
• The Idea behind fixed time frames is taken from Scrum. Scrum works with Sprints (fix starting date, fix ending date) and already has predefined userstories before starting the sprint. The stabilzation cycle has a fix starting date and a fix ending date too, but the functionalities must not (but can) be predefined in advance.

See Also

• Community Governance‎