lustre/doc/VERSIONING

   1 Lustre versioning
   2 =================
   3
   4 0.0.1  2/19/2002 <braam@clusterfs.com>
   5 0.0.2  3/14/2002 <braam@clusterfs.com> describe branches / stable tag
   6 0.0.3  6/10/2002 <braam@clusterfs.com> describe release mechanisms
   7
   8 This document describes versioning of source and binaries for Lustre.
   9
  10 Packages
  11 ========
  12
  13 RPM's that you build should get 3 figure versions, CVS versions will
  14 be 4 digits, and can correspond to test RPM's, and lead up to the
  15 package version.  So let's plan on releasing
  16
  17 So you'd build 2 sets of test rpms this week:
  18
  19 0.0.9.1
  20 0.0.9.2
  21
  22 we decide it's fine then and we release
  23
  24 0.1.0
  25
  26 We go on developing with
  27
  28 0.1.0.{1,2,3,4,...}
  29
  30 as test releases and then we release:
  31
  32 0.1.1
  33
  34 The 0.1 sequence is an unstable sequence, like 2.5 for the kernel is.
  35 So we expect lots of 0.1.X releases leading up to a stable 0.2 (or
  36 1.0) at the time of deployment.
  37
  38 CVS
  39 ===
  40
  41 Versions will have 4 digits:
  42                      major.minor.patch.test
  43
  44 Such versions will be tagged in CVS as:
  45                      v1_2_11_7
  46 and referred to as:
  47                      1.2.11.7
  48 encoded as:
  49                      0x01021107
  50
  51 Usage:
  52 ------
  53
  54 New numbers are used as follows:
  55
  56 1. major:
  57  - increased when major new functionality becomes available
  58 2. minor:
  59  - even: for each new release with new functionality
  60  - odd : when a new development cycle starts after a release
  61 3. patch:
  62  - when a development snapshot or release update becomes available
  63  - all these are announced on lustre-devel@lists.sf.net
  64 4. test:
  65  - when developers feel it is time to exchange a named version
  66
  67 What will run, what won't ?
  68 ---------------------------
  69
  70 1. If the test level is non-zero, i.e. there are 4 digits in the
  71    version, no guarantees of any kind are made.
  72
  73 2. For three digit releases/tags the code should perform
  74    according to the announcement.
  75
  76 Moving tags
  77 -----------
  78
  79 The last stable release will be tagged:            CVS tag "t_last_stable"
  80 The last operational development snapshot will be  CVS tag "dstable"
  81
  82 Branches
  83 --------
  84
  85 For even minor releases a branch tag will be created.  The branch tag
  86 will be of the form:
  87
  88 bmajor_minor
  89
  90 Note that the CVS head is where development is going.  If developers
  91 use a branch they must eventually merge that back into the head.
  92 Typically this is done by importing changes into the branch and
  93 removing the sticky tags:
  94
  95 cvs update -A
  96
  97 fixing any conflicts and then committing.