Development Process
From ArgeoWiki
The most important assest of Argeo is its development methodology. It is described here and related pages.
Contents |
The Golden Rule
Every new feature of a system, software or library should be defined in requirements (from a functional point of view) and its implementation should be proposed in a design (from a technical point of view). Even if each is made out of one single sentence.
The preferred place for incrementally producing and refining requirements and design is this wiki for public projects or each project wiki for the private projects.
From our experience, we believe that most of the delays and related costs in IT projects come from unclear requirements and lack of design. Before any implementation starts there should be a discussion between functional and technical actors (even if they are one single person), whose result can be seen as a "contract", which will serve as reference for scheduling, priority setting, technical and functional testing, rescheduling and final acceptance.
We insist on this even more than on testing because we believe that:
- it induces a positive dynamic: as soon as you start to try naming things and write them down, the real difficulties naturally pop-up, and you are naturally inclined to address them before the cost of implementing/testing/deploying occurred.
- regarding tests, we believe that you have to test anyhow. Who is fool enough to do it in production with you end users, or masochist enough to do it manually instead of trying to automate it as much as reasonably feasible? (Plenty of projects, we know...). More seriously: tests comes naturally in the development process and are easy to define and implement, as soon as the requirements/design iteration has been properly done.
Versioning
Version Naming Conventions
Projects release are versioned with the form major.minor.release (e.g: v1.3.2, v2.6.8, v0.1.6):
- major: stands for big architectural changes. Upgrading from a major version to another will most probably imply a migration.
- minor: stands for new features. Upgrades to higher minor versions should be backward compatible (e.g: v1.6 should run transparently on 1.4 data/configs, but there is not guarantee that v1.4 could run on v1.6 data/configs).
- release: identify an officially published release. For stable streams (see below), each release should be backward and forward compatible (e.g: v1.6.3 can run on v1.6.5 data/configs, and v1.6.5 can run on v1.6.3 data/configs)
Odd/even Versioning Rule
All Argeo projects (public and private) follow the odd/even versioning rule (a standard in OpenSource, if not the only one):
- new features are added in a development stream which has an odd minor version (e.g. v0.7, v2.9). This code is not supposed to be stable and releases are only targeted to developers or testers. The last releases are release candidates where no more features is added, but which are intensively tested in order to fix as many bugs as possible. When a release candidate is deemed stable enough for production usage, a stable stream is created with an even minor version (e.g. v0.7 => v0.8, v2.9 => v2.10). The next development stream (with odd minor version) can be created immediately or later on from the stable stream.
- only bugs are fixed in a stable stream which has an even minor version (that is, no new feature is added, limited enhancements are acceptable). Only releases with even minor versions should be put in production.
This rule implies:
- there can be only one development stream per project, but many parallel streams can be alive (they are the supported versions).
- it makes no sense to defined requirements or specs for a development stream: a development stream only prepares the next stable stream (the goal is to be in production in the end!). There fore requirements and design wiki pages should only refer to stable streams (that is, with even minor numbers: v0.2, v0.4, v1.6, v2.8, etc.)
