X-Git-Url: https://git.whamcloud.com/?a=blobdiff_plain;f=lustre%2Fdoc%2FVERSIONING;h=3ed1c7eefabf604ca2855f06e1f91185989de59c;hb=2a38589c6ea247eabf530888912fe555a07252d4;hp=a1a8b62265db21b7cb1f4d429de1430ff918691a;hpb=94c2ba8fc1b4f13c29231f84d18ac3b7ade2d5ed;p=fs%2Flustre-release.git diff --git a/lustre/doc/VERSIONING b/lustre/doc/VERSIONING index a1a8b62..3ed1c7e 100644 --- a/lustre/doc/VERSIONING +++ b/lustre/doc/VERSIONING @@ -1,97 +1,52 @@ Lustre versioning ================= -0.0.1 2/19/2002 -0.0.2 3/14/2002 describe branches / stable tag -0.0.3 6/10/2002 describe release mechanisms - This document describes versioning of source and binaries for Lustre. -Packages +Versions ======== -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: - -0.0.9.1 -0.0.9.2 - -we decide it's fine then and we release - -0.1.0 - -We go on developing with - -0.1.0.{1,2,3,4,...} - -as test releases and then we release: - -0.1.1 +The Lustre build version is set in lustre/autoconf/lustre-version.ac +file with the LUSTRE_MAJOR, LUSTRE_MINOR, LUSTRE_PATCH, and LUSTRE_FIX +fields. These are used to generate the LUSTRE_VERSION string and the +LUSTRE_VERSION_CODE in lustre/include/lustre_ver.h. -The 0.1 sequence is an unstable sequence, like 2.5 for the kernel is. -So we expect lots of 0.1.X releases leading up to a stable 0.2 (or -1.0) at the time of deployment. +LUSTRE_VERSION_CODE can be used in conjunction with OBD_OCD_VERSION() +to conditionally enable functionality by Lustre version, or to mark +some part of code obsolete when a future version of Lustre is built. +It is preferable to mark code obsolete starting at the x.y.50 build +so that it is removed early in the development cycle. -CVS -=== +Packages +======== -Versions will have 4 digits: - major.minor.patch.test +Major releases should get a 3-digit version x.y.0, and if a maintenance +release is needed it will increment the 3rd digit. During development, +versions start at x.y.50 and increment toward the x.(y+1).0 release. -Such versions will be tagged in CVS as: - v1_2_11_7 -and referred to as: - 1.2.11.7 -encoded as: - 0x01021107 +Release candidate versions must have the proper build version for the +release, but are tagged in Git as v2_1_0_RC1. Final release versions +are tagged in Git as both v2_1_0_0 and 2.1.0. -Usage: +Usage: ------ -New numbers are used as follows: +New numbers are used as follows: -1. major: +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 +2. minor: + - for each new release with new functionality 3. patch: - - when a development snapshot or release update becomes available - - all these are announced on lustre-devel@lists.sf.net -4. test: + - for a stable maintenance release or development snapshot +4. test: - when developers feel it is time to exchange a named version -What will run, what won't ? +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 +2. For three digit releases/tags the code should perform according to the announcement. - -Moving tags ------------ - -The last stable release will be tagged: CVS tag "t_last_stable" -The last operational development snapshot will be CVS tag "dstable" - -Branches --------- - -For even minor releases a branch tag will be created. The branch tag -will be of the form: - -bmajor_minor - -Note that the CVS head is where development is going. If developers -use a branch they must eventually merge that back into the head. -Typically this is done by importing changes into the branch and -removing the sticky tags: - -cvs update -A - -fixing any conflicts and then committing.