QB2: Scripting for build version #501

ALG4 · 2 decades ago

Hi,

I was wondering if this is possible to do with built-in scripting for the build version. Our version strings have a different format, depending on whether the version is a patch release, or GA. A '-{patch letter}' is appended to the major.minor.buildNo string if it is a patch release. Also, for GA the build number is incremented with every build, but not for a patch.
GA: 8.2.916
Patch: 8.2.916-A

With QB1, we manually change the format in the build version field once a GA release has gone out, as it will never need to increment the build number again, and will always have the patch letter at the end. Is it possible to script this if a variable was set, like "patch=1"?

Thanks.

replies 5
views 2362
stars 0

robinshen ADMIN · 2 decades ago

Does this mean that after GA, the build version will keep unchanged and remains the same no matter how many patch builds are built?

Thanks
Robin

ALG4 · 2 decades ago

We do have a fourth "internal" build number that will increment (which is removed when released) for patches, since the official build number is frozen after GA. But this isn't a problem because we increment the number during GA builds as well (alongside the real build number).
Like this:

GA:
{major}.{minor}.{build(increase)}.{devbuild-increase}

Patch:
{major}.{minor}.{build(static)}.{devbuild-increase}-{patch letter}

robinshen ADMIN · 2 decades ago

You may specify the build version as:

8.2.${
if (vars.getValue("patchLetter")!=null) {
  return vars.get("buildNumber") + "." + vars.get("devBuildNumber").increase() + "-" + vars.get("patchLetter");
} else {
  vars.get("buildNumber").increase();
  return vars.get("buildNumber") + "." + vars.get("devBuildNumber").increase();
}
}

The variable patchLetter, buildNumber and devBuildNumber need to be defined. When patchLetter is defined as an empty value, buildNumber and devBuildNumber will be increased. After GA, if patchLetter is set to a fix value for example, only the devBuildNumber will be increased.

Regards
Robin

ALG4 · 2 decades ago

Thanks, that does the increase, however the variables are stored in the parent configuration, and I'd like to save the increase to there. I tried this:


${vars.get("major")}.${vars.get("minor")}.${
   if (vars.getValue("patch")!=null) {
      vars.get("devBuild").setValue(vars.get("devBuild").increase(0),0);
      return vars.get("build") + "." + vars.get("devBuild") + "-" + vars.get("patch");
    } 
   else {
      vars.get("build").setValue(vars.get("build").increase(0),0);
      return vars.get("build") + "." + vars.get("devBuild").increase();
    }
}

but it seems to not do the increase. The original variable value is being returned.

robinshen ADMIN · 2 decades ago

In 2.0 beta2, we only allow to increase variable in current configuration since otherwise concurrent modifications to parent configurations will happen which may cause weird problems when multiple child configurations are run in parallel. We will check to see if we can lock parent configurations in beta3 so that variables can safely be stored into the configuration where it is defined in without noticable performance degration (all ancestor configurations need to be locked since we do not know which variable is defined in which configuration unless we read them out, and the lock can only be released until there are no possible modifications to the variables which is hard to guess since QuickBuild supports scripting everywhere).

Thanks
Robin