Lustre discuss - Feb 2010 - How builds will be numbered in future Lustre releases

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

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
> 
>

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
>>
>>
>

hi Christopher,

Yes, we''re updating lustre-version.ac - you can follow the progress 
under bug #22234. 

I think we should be able to accommodate your request to add the 
additional field you mentioned.  Could I ask you to file a bug for this 
and cc: me? 

As for replacing the timestamp with "git describe", I think
that''s a
worthwhile discussion.  Does anyone on this list see any reason we 
shouldn''t do this?

kind regards,
melanie

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
>>
>>
>

melanie gao wrote:
> Yes, we''re updating lustre-version.ac - you can follow the
progress
> under bug #22234.
> I think we should be able to accommodate your request to add the 
> additional field you mentioned.  Could I ask you to file a bug for this 
> and cc: me?
Done.  For everyone''s reference I filed this is in bug 22281.

hi Christopher,

I didn''t see any discussion on this alias about replacing the timestamp
with ''git describe''.  I''m not sure if that means
there are no objections
or if folks just didn''t raise their objections in this forum.  Just to 
make sure we don''t lose track of the request could you file a bug for 
this one as well?  Meanwhile I''ll ask our RMG (Release Mgmt. Group) to 
follow up and see if it''s something we can/should implement.

kind regards,
melanie

melanie gao wrote:
> hi Christopher,
>
> Yes, we''re updating lustre-version.ac - you can follow the
progress
> under bug #22234.
> I think we should be able to accommodate your request to add the 
> additional field you mentioned.  Could I ask you to file a bug for 
> this and cc: me?
> As for replacing the timestamp with "git describe", I think
that''s a
> worthwhile discussion.  Does anyone on this list see any reason we 
> shouldn''t do this?
>
> kind regards,
> melanie
>
> 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
>>>
>>>
>>
>