OOPM:Development:Documentation:Development Process
From Apache OpenOffice Wiki
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
Side Notice: part of the information provided here is based on a development process that is in the works for quite some time now, initially conceived by User:Carsten.klein, losely based on existing other processes such as RUP, XP, VModel(-XT) and so on. We will be customizing this process as required, given the current number of personnel.
- Process
- iterative and hopefully "agile" process
- however, we will not be using an adhoc process whilst developing in the alpha alpha or subsequent, more stable phases of our product,
- adhoc only applies to the prototype phases, for example the proto proto phase to up until the proto beta phase, or the alpha proto/beta proto/stable proto phases
- we will use assigned roles and assigned tasks
- every change to our software system, except during the initial prototyping and learning phase will be based on assigned tasks, also given a fore-front specification of what must be done
- 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
- continuous integration applies
- we will be using the ci facilities provided by the OOo project, requires more research into available toolings/tool chains though
- we will do architecture and design incl. also specification prior to actual development to assure that we will always deliver a (rather) stable product once it has been released and future feature development takes place
- we will be doing feature development and maintenance development, for this we will use so-called (feature) development branches and maintenance branches with the individual components of our software system
- 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 ;)