doc/toWiki/development_practices.txt

   1 Indico development practices and version releasing policy
   2 =========================================================
   3
   4 0. Purpose of this document
   5
   6 This document aims at describing the suggested way for working with the code
   7 repository when developing for the Indico project.
   8 Currently the Indico sw went into production but the project still goes on as
   9 we are implementing new features. This is a problem because we need to keep
  10 separated versions for developing and fixing eventual bugs or enhancements in
  11 the "production" code. CVS and its branching facilities will be used for this
  12 purpose and this document tries to describe how this will be carried out within
  13 the project.
  14
  15
  16 1. Basic releasing policy
  17
  18 In our scope a "release" means a version of the Indico sw which has been fully
  19 tested and verified to accomplish minimal quality levels and which is ready for
  20 production. Each release will be uniqely identified by a "version number" which
  21 will have the form: "{major version #}.{minor version #}.{patchlevel #}"
  22     + major version #: will be incremented each time there's an important
  23         change in the sw (architectural, technological, iteration, ...)
  24     + minor version #: will be incremented each time a new feature is
  25         added to the sw.
  26     + patch level #: will be reserved for patch releases.
  27
  28
  29 2. Releasing
  30
  31 CVS is used as code repository for the project. It is important that the release
  32 policy is reflected in our CVS so we can, at any time access or generate any
  33 release of the code.
  34 For this purpose, each code release must be tagged in the CVS in the form:
  35 "release_{major version #}.{minor version #}". After tagging any release,
  36 the responsible must make to sure that the system is working and installing
  37 fine by retrieving a fresh checkout of the code for the new tag and performing
  38 the required tests. New developement will be always in the main trunk and only
  39 release tag will ensure the stability of the code.
  40 Once a release is confirmed, a new branch must be created. This new branch must
  41 be tagged in the form "release_{major version #}.{minor version #}.0". This new
  42 branch is reserved for bugfixes and patch releases so developement can go on
  43 in the trunk.
  44
  45
  46 3. Patch releasing
  47
  48 As it was said above, once a release is confirmed a new branch must be
  49 created. The tag for the new brach will follow the pattern
  50 "release_{major version #}.{minor version #}.0" related to the confirmed
  51 release.
  52 Every bugfix of a release must be done on the branch and once a bugfix
  53 (or a set of them) is done, the results must be committed to the branch and
  54 a tag must be set increasing the patch level number in one.
  55 After the patch release is tested, checked and so on, a merging with the trunk
  56 must be carried out resolving possible conflicts which may appear. Once the
  57 conflicts are solved the new code must be committed and the trunk must be
  58 tagged in the form "merged-release_{major ver #}.{minor ver #}.{patch level #}".
  59
  60
  61 4. References
  62
  63 [1] Version management with CVS <http://www.cvshome.org/docs/manual/>
  64 [2] Open source development with CVS <http://cvsbook.red-bean.com/>
  65 [3] CVS best practices <http://www.magic-cauldron.com/cm/cvs-bestpractices/>