4 This document describes versioning of source and binaries for Lustre.
9 The Lustre build version is set in lustre/autoconf/lustre-version.ac
10 file with the LUSTRE_MAJOR, LUSTRE_MINOR, LUSTRE_PATCH, and LUSTRE_FIX
11 fields. These are used to generate the LUSTRE_VERSION string and the
12 LUSTRE_VERSION_CODE in lustre/include/lustre_ver.h.
14 LUSTRE_VERSION_CODE can be used in conjunction with OBD_OCD_VERSION()
15 to conditionally enable functionality by Lustre version, or to mark
16 some part of code obsolete when a future version of Lustre is built.
17 It is preferable to mark code obsolete starting at the x.y.50 build
18 so that it is removed early in the development cycle.
23 Major releases should get a 3-digit version x.y.0, and if a maintenance
24 release is needed it will increment the 3rd digit. During development,
25 versions start at x.y.50 and increment toward the x.(y+1).0 release.
27 Release candidate versions must have the proper build version for the
28 release, but are tagged in Git as v2_1_0_RC1. Final release versions
29 are tagged in Git as both v2_1_0_0 and 2.1.0.
34 New numbers are used as follows:
37 - increased when major new functionality becomes available
39 - for each new release with new functionality
41 - for a stable maintenance release or development snapshot
43 - when developers feel it is time to exchange a named version
45 What will run, what won't ?
46 ---------------------------
48 1. If the test level is non-zero, i.e. there are 4 digits in the
49 version, no guarantees of any kind are made.
51 2. For three digit releases/tags the code should perform
52 according to the announcement.