The new build system can do a build given either a branch or a tag, like the
previous system. But moving to a model where we tag regular "builds" might
address the issue at hand, so a specific build might be called something
like v1_4_8_build2 and there would be a tracker bug which shows exactly
what was included in 1.4.8 build 2.
-andy
Peter Braam wrote:
I think that when (sic) we switch to an scm system that has absolute,
easily identifiable versions, such as svn, we can omit this. As long as
multiple builds of things with the same tag (or lack thereof) are
possible this tag isn't so helpful.
We nearly have automatic builds going - I believe that these build
branches not tags and that we need some kind of identifier. Andy - is
that right?
- Peter -
Nathaniel Rutman wrote:
Absolutely not out of line; we're sending all this stuff to
lustre-devel expressly
so that anyone can comment.
[EMAIL PROTECTED] wrote:
Please don't reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=11486
This comment may be out of line, but I'm not sure it's a good idea to
stop using
BUILD_VERSION. While very verbose & sometimes confusing, we very
frequently
build multiple versions of lustre from the same source base. These
mostly vary
in small ways, which patches for bugfixes are added, etc. In such
cases the
LUSTRE_VERSION_STRING doesn't change & the BUILD_VERSION appearing at
runtime in
server logs in startup msgs is the only way to identify precisely
what is running.
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
