VERSIONING

Lustre versioning
=================

0.0.1  2/19/2002 <braam@clusterfs.com>
0.0.2  3/14/2002 <braam@clusterfs.com> describe branches / stable tag
0.0.3  6/10/2002 <braam@clusterfs.com> describe release mechanisms

This document describes versioning of source and binaries for Lustre.

Packages
========

RPM's that you build should get 3 figure versions, CVS versions will
be 4 digits, and can correspond to test RPM's, and lead up to the
package version.  So let's plan on releasing

So you'd build 2 sets of test rpms this week:

1.6.8.91
1.6.8.92

we decide it's fine then and we release:

1.6.9

If there are critical hotfixes that need to be released to customers
(e.g. data corruption fixes) then point releases would be created:

1.6.9.{1,2,3,...}

We go on developing with

1.6.9.{91,92,93,94,...}

as test releases and then we release:

1.6.10

The 1.7 sequence would be an unstable sequence, like 2.5 for the kernel
is.  So we expect lots of 1.7.X releases leading up to a stable 1.8 (or
2.0) at the time of deployment.

CVS
===

Versions will have 4 digits:
                     major.minor.patch.test

Such versions will be tagged in CVS as:
                     v1_6_9_97
and referred to as:
                     1.6.9.97
encoded as:
                     0x01060961

Usage:
------

New numbers are used as follows:

1. major:
 - increased when major new functionality becomes available
2. minor:
 - even: for each new release with new functionality
 - odd : when a new development cycle starts after a release
3. patch:
 - when a development snapshot or release update becomes available
 - all these are announced on lustre-{announce,devel}@clusterfs.com
4. test:
 - when developers feel it is time to exchange a named version

What will run, what won't ?
---------------------------

1. If the test level is non-zero, i.e. there are 4 digits in the
   version, no guarantees of any kind are made.

2. For three digit releases/tags the code should perform
   according to the announcement.

Branches
--------

Any and all development must be done on branches, and can only merge to the
HEAD if _at_least_ tests/acceptance-small.sh and IOR with 5 SMP nodes and
2 clients/node with 1GB file/client pass without any errors or cleanup
problems.  Additional tests may be added in the future, so the tests in the
current CVS head must pass before a branch can be merged back to the trunk.

See http://lustre.org/docs/branches.html for details on CVS branch usage.