[Lustre-discuss] How builds will be numbered in future Lustre releases

[Christopher J. Morrone]

I assume that there will be some modifications to 
lustre/autoconf/lustre-version.ac and elsewhere to support this?

While you are in there, I'd like to request that you add a field for 
third-party folks to add their own version.  For instance, we add a 
"-20chaos" tag to our version numbers to distinguish them from 
Sun/Oracle releases.  But to get that number into Lustre we are 
currently using the LUSTRE_VERS environment variable, which has at least 
two problems:

1) Our branch of lustre does not contain OUR version number.  All of the 
scripting to embed our additional version number are in external 
scripts.  If someone takes one of our tags and builds it, the resulting 
rpm will have a normal upstream version number.  That could lead to 
unnecessary confusion about what they are running.

2) Our automated rpm builder operates on src rpms only.  Unfortunately, 
even if we set LUSTRE_VERS when we generate the src rpm, that version 
isn't retained anywhere when the binary rpms are built from the src rpm. 
  So we wind up having scripts to rewrite the spec on the fly to embed 
the version number.

It would just be alot easier if there was an additional version field 
for third-parties.

To digress further:

Now that we are all using git, the date that is embedded in snapshot 
builds of lustre is not terribly useful.  I would like to propose that 
we start using "git describe" instead of a timestamp.  For those that 
haven't seen that command before:

$ git describe
1.8.2.0-20chaos-2-g4d485b2

That says that I am currently 2 commits beyond the refspec 
1.8.2.0-20chaos (an annotated tag in this case, but it could also be a 
branch name), and the commit is 4d485b2.  (No, I don't know why the "g" 
is in there. :))

If that is too long, maybe just a commit number?

Melanie Gao wrote:
> hello Lustre users,
> 
> My name is Melanie Gao.  I'm a program manager in the Lustre team and
> will be managing the release that comes after 2.0.
> 
> We're making some changes to the way we number Lustre builds and I
> wanted to give you a heads-up.  Here's a summary of the changes:
> 
> 1. The first build of a release will be called 2.x.0.001.  So for
> example for a Lustre 2.1 release, the first build would be 2.1.0.001.
> 
> 2. We will increment the dot-dot-dot numbers monotonically (by one's
> instead of by ten's).  That is to say, the builds will be numbered as
> follows:
> 2.1.0.001
> 2.1.0.002
> 2.1.0.003
> 
> 3. We will append "alpha" or "beta" at the end of every build so that
> it's clear that it's not the GA build.  If the build is a milestone
> build we'll append "alpha1" or "beta1".  That is to say, the builds will
> be numbered as follows:
> 2.1.0.001.alpha (not a milestone)
> 2.1.0.002.alpha (not a milestone)
> 2.1.0.003.alpha1 (first alpha milestone build)
> 2.1.0.004.alpha (not a milestone)
> 2.1.0.005.alpha2 (second alpha milestone build)
> ...
> 2.1.0.012.beta1 (first beta milestone build)
> 2.1.0.013.beta (not a milestone)
> 2.1.0.014.beta2  (second beta milestone build)
> 
> 4. The final GA build will have nothing appended at the end but we
> will make it clear when we release it that it's the GA build.  Assuming
> build 35 was the GA build for Lustre 2.1, the final build number
> would be 2.1.0.035.
> 
> If you have any questions please respond to this email and I'll be happy
> to answer them.
> 
> kind regards,
> melanie
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
> http://*lists.lustre.org/mailman/listinfo/lustre-discuss
> 
>