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

[Melanie Gao]

hi Christopher,

Thanks for bringing up these questions.  I'll get back to you asap with 
answers.

kind regards,
melanie

On 02/27/10 07:42, Christopher J. Morrone wrote:
> 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
>>
>>
>