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

From Apache OpenOffice Wiki
Jump to: navigation, search
(Development Process)
Line 15: Line 15:
 
* release oriented
 
* release oriented
 
* 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
 
* 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
 
;Versioning/Branching
  

Revision as of 17:21, 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
  • release oriented
  • 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 ;)
Personal tools