Difference between revisions of "OOPM:Development:Documentation:Development Process"

Revision as of 17:32, 21 April 2009

TBD make this use the single page, unversioned document template

Development Process

TBD this is currently a stub, we will continue improving this article in the near future as soon as the issues have been settled and the general direction of development was given

Process

• iterative and hopefully "agile" process
• we will use assigned roles and assigned tasks
• we will be using change package oriented development, i.e. goals set forth in the individual iteration statements in this wiki and we will integrate the issue tracker
• we will use the bug/issue tracker for capturing our advancement during development and we will check-in so that we can track down individual changes made to

the individual change packages set forth by the issues in the issue tracker

• source release oriented

we will do source releases until we reach the public beta phase

until then we will not fuss around with build numbers and the likes

and, when we reach the public beta phase, we will use the revision number part of our binary release version for the actual build number instead

of introducing yet another versioning scheme

TBD move above information to OOPM:Development:Documentation:Versioning

• test driven development -- since we set out to create a headless backend we can test the backend incl also the datamodel using automated tests, for the user interface we will have to yet define the testing suites that we will use
• we will be using multiple subprojects for our software system, and by that also multiple locations in the cvs

at least one per component or bundle of associated components, e.g. type libraries and so on

for integration we will be using a second component that will feature the toolings required to fully integrate the existing components into either backend or frontend

Versioning/Branching

See existing document on versioning OOPM:Development:Documentation:Versioning

• release state denotes overall development state, e.g. proto for a prototype, alpha, beta, stable and so on
• version state denotes overall state of the release version, e.g. proto for a prototype, alpha, beta, stable and so on
• upon stabilization for a (final) stable release, we will be using release candidates before we will ship the then hopefully stable version to the public

Q/A

• we will use closed (internal) prototype testing
• we will use closed (internal) alpha testing
• we will use public beta testing
• we will use public release candidate testing
• stable banana releases we provide will also use a public testing process ;)