Is seem that currently it is impossible to user values of already defined parameters in order to simplify parameter usage and avoid repetition (DRY principle).

I will give this bash example in order to explain value expansions as they work in bash (probably the most known syntax.

#!/bin/bash
PARAM1="AAA"
PARAM2="Some $AAA text"
PARAM3="Other ${AAA} text"
PARAM4="3th example which resolves ${AAA:-ZZZ} as ZZZ when AAA is not defined"

If we want to put these 4 parameters in Jenkins we have no option for allowing the user to than only the value of PARAM1, because Jenkins does not perform variable expansion of the default values.

You may wonder why this is so important because sounds like a really weird use case. For this reason I will provide one screenshot from our current build parameters.

As you can imagine we do have other branches for other numeric values than "11.0". At this moment if a user wants to build a specific branch they are forced to copy paste branch name in 3 different parts on these params.

Wouldn't it be easier if we could add an initial parameter which would contain only 11.0 and expand this param inside the default values of GERRIT_REFSPEC and GERRIT_BRANCH? Maybe we could even use the dropdown values for this parameter.

Why we cannot compute later the GERRIT_REFSPEC and GERRIT_BRANCH values? — these parameters are used by various plugins so there is place where these can be re-processed. Maybe there are some workarounds for jobs using pipelines for these would work exclusively for pipelines and we think that this deserves a generic implementation that is not dependent on the job type.

As a last note, it seems that we are not the only ones that are wondering about expanding variable as I observed an extremely similar bug JENKINS-17755 raised against the release plugin.