I had hoped that we could use a midstream and downstream branch both set to the same value that is expected from Brew / pkgs.devel repos / Errata / product requirements – this was a simplification done to make it easier to manage the migration from old jenkins to new casc Jenkins, and to use the correct official conventions needed for downstream.

But it's been brought to my attention that this is confusing when contributors want to submit PRs syncing changes from upstream Che master branches to midstream crw-2-rhel-8 branches, even though it simplifies the Jenkinsfiles & transformation code between mid and downstream (see CRW-1275).

It's unclear who these confused contributors are, as we only have RH personnel contributing to CRW, and so far, they've been able to successfully submit PRs and cherrypick PRs against multiple repos (server/registries, theia, crwctl, operator).

Today:

SOURCE_BRANCH = 7.yy.x or master
MIDSTM_BRANCH = crw-2.y-rhel-8 or crw-2-rhel-8
DWNSTM_BRANCH = MIDSTM_BRANCH [variable not needed, code is simpler]

Future, preferred by devex team:

SOURCE_BRANCH = 7.yy.x or master
MIDSTM_BRANCH = crw-2.y-rhel-8 or main
DWNSTM_BRANCH = crw-2.y-rhel-8 or crw-2-rhel-8 [variable needed, with additional rule to align stable branch vs. nightly branch as they adhere to different conventions]

As this requires the reintroduction of a 3rd branch variable to support sync jobs between the 2 dozen upstream repos and their downstream equivalents, this is tech debt that can be addressed after we handle some more pressing issues, like:

• enabling CI builds in parallel with ER/RC/stable branch builds, to enable CRW builds as PR checks against upstream changes in Che
• migrating to CPaaS
• reintroducing Freshmaker for CVE respins in operator metadata
• updating registries to be closer aligned to upstream
• improving communication around Che / CRW releases (better automation)
• introduction of 4-5 new containers in support of Devfile 2.0