Previous Next
Auth_Container_RSDB MagicQuotesUtil

EVS

Easy Versioning System

Introduction

EVS is part of RSD - the Rapid and Secure Development Project. When a project is created with versioning support the directory structures described by RSD (RSDEngine - The Rapid and Secure Development Engine and RSDEngine - The Rapid and Secure Development Engine do not directly reside in the projcet directory (the project root) but in a subdirectory named like the version number.

Versioning - EVS

The naming of versions follows these rules:

  • All version names are coposed in three parts seperated by dots: major.minor.revision.
  • Even minor releases (eg 1.2, 2.6) are stable, uneven minor releases (0.1, 1.3) are development releases and therefore unstable.
  • In a stable branch (eg 0.2, 1.0) the patchlevel releases contain only bugfixes! In development branches (eg 0.1, 1.1) they can contain new features and bugfixes.
  • For each minor release there is a current version named $major.$minor.current (eg 0.1.current, 1.2.current). Development takes only place in these versions.
  • New features are only added in the latest current development version.
  • Major releases indicate that the new release is not downward compatible or at least somehow revolutionary.
  • The first public release is 1.0.0.
Developers will mostly make patchlevel releases - at the beginning they get the project specification which is implemented and tested until it is considered stable and the first public releas is made (1.0.0). This release is sold to the customer. So there will never be a 0.2 (stable but not public release) in some projects. So major releases should be very rare. Have a look a the development of the Linux Kernel at http://www.kernel.org. They use the major.minor.revision convention as well. Their last major release is years ago.

Let's go through an imaginary scenario of application development:

  • The project manager hands the project specs to the developers. They create a new project using versioning. This means a version named 0.1.current will be created.
  • They hack around for a while and at some point they feel that the featurs A and B are done and ready for testing. They make their first patchlevel release 0.1.0 and report that to the quality assurance department.
  • While the quality assurance department starts testing, the developers start implement the missing features C and D.
  • When they are done, they make the new patchlevel release 0.1.1 and report that again to the quality assurance department.
  • When the quality assurance department reports the bugs #37 and #39 found in 0.1.0 and 0.1.1 they get fixed by the developers in the current development version 0.1.current. Afterwards the new patchlevel release 0.1.2 is made.
  • After final testing the first stable release can be made. If this stable release is a public release, make it a major release (1.0.0). If it is not a public release make it a minor release (0.2.0). Here we make it a public release. When making the major release 1.0.0 the obligatory 1.0.current development version will be created as well.
  • When the bugs #40 and #41 are reported in the public release (1.0.0) the current version of the stable release (this means 1.0.current) gets patched by the developers and the new patchlevel release 1.0.1 will be made.
  • After some time the customer requests the new feature E. New features can only be added in a current development version. 1.0.current is not a development version (the minor is even!), so we need to make a new minor release: 1.1.0. When making this minor release, the obligatory 1.1.current development version will be created as well. The new feature E can now be implemented in 1.1.current. After doing so, the patchlevel release 1.1.1 will be made to allow the quality assurence department to perform some testing. The reported bugs #45 and #51 will get fixed in 1.1.current and a the new patchlevel release 1.1.2 can be made. When the quality assurence department performed their final tests the new (stable!) minor release 1.2.0 can be made. 1.2.0 can now be distributed to the customer.

The ChangeLog of 1.2.0 could look like this:

------- 1.2.0 released on Sunday 15th of June 2003 18:59:05 -------
We are very proud to anncounce the new release 1.2 which provides
the new feature E!


------- 1.1.2 released on Sunday 15th of June 2003 18:58:09 -------
The bugs #45 and #51 were fixed.


------- 1.1.1 released on Sunday 15th of June 2003 18:57:38 -------
The feature E was implemented.


------- 1.1.0 released on Sunday 15th of June 2003 18:56:26 -------
In this release our application is in the state of the 1.0 branch
at the time the 1.1 branch forked. In the 1.1 branch the feature
E will be implemented.


------- 1.0.1 released on Sunday 15th of June 2003 18:55:35 -------
The bugs #40 and #41 were fixed.


------- 1.0.0 released on Sunday 15th of June 2003 18:43:51 -------
We are proud to announce the first stable release!

------- 0.1.2 released on Sunday 15th of June 2003 18:42:19 -------
All known bugs including #37 and #39 have been fixed.

------- 0.1.1 released on Sunday 15th of June 2003 18:40:52 -------
Additionally to the features A and B, C and D are new implemented
as well!


------- 0.1.0 released on Sunday 15th of June 2003 18:40:39 -------
The following feature were implemented: A, B
	

Previous Next
Auth_Container_RSDB MagicQuotesUtil

Documentation generated on Mon, 8 Dec 2003 13:09:32 +0100 by phpDocumentor 1.2.3