Details
-
Bug
-
Resolution: Low Priority
-
Minor
-
None
-
None
-
None
-
3
-
10729
Description
During the RC build for 2.1.2 the lustre version update was forgotten. There used to be code in configure which detected exactly such a mistake and broke the build because of it. It was put there for exactly this situation. c487014a39a6e37dc22a957aad9ad9b739e3c8cf was landed for LU-278 which changed this error into a warning, of course, hiding the breakage.
Indeed, it is always nice when manual processes (such as incrementing the bits for a new release) go off without a hitch, but having checks to make sure we do them all is probably even better.
I'm still not convinced that the claims of the problems that were being made about that version/tag check in LU-278 were all true but it seems a patch was landed anyway. That is, I'm not convinced that any old tag on a branch would cause configure to error out as was being claimed since the format of tags being looked at is pretty strict.
I propose that the claims in LU-278 be verified as either true or not and if found to be untrue, reverting c487014a39a6e37dc22a957aad9ad9b739e3c8cf so that we don't have this problem in the future.
An alternative would be to add (yet) another switch to configure which toggles whether the checking code is to produce a warning or an error, defaulting to a warning. We could then add that switch to our jenkins build steps so that a tag/version mismatch produce a configure error for our builds causing the build to fail.