Release candidate versioning is inconsistent

Ceri Williams in customer environments - only released versions should be used.

you perhaps misread my comment.

Evgeniy Patlan well, we need a reliable way to be able to restrict versions allowed in customer enviornments, check where versions mismatch and also be able to deploy FB, RC and GA releases with automation, without rewriting everything done so far and without breaking anything already using something related

• We need to be able to restrict versions available in customer environments

• We need to check the client and PMM server versions via automation, the reported version should match the version used to deploy it

• We need the ability to be able to deploy FB and RC where we define it is allowed, but they need to match the same mechanisms used for releases

What we have now is:

• fully automated management of the server and client, including enforced versions

What we have issues with:

• aside from the location, there is no difference in reported version from a release candidate and a released version - which clearly are not the same version

• feature branches report a different version to a release or candidate version, but do not match the version used to deploy.

You can see the issues here:

https://jira.percona.com/browse/PMM-5607?focusedCommentId=282045&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-282045

From what you have shown above, I see no difference and only overly complicated options for automation.

in customer environments - only released versions should be used.

As for testing automation, so far we don't support automatic updates from any repos to any repos.

all the packages have same version scheme in all repos. They differs only by commit and build time, RC and released package version matches completely as we don't rebuild them and just copy to the released repo.

Version scheme is defined by build script:

https://github.com/Percona-Lab/pmm-submodules/blob/PMM-2.0/build/bin/vars#L13

will be changed by https://github.com/Percona-Lab/pmm-submodules/pull/1730

that only addresses the current issue with the version show in pmm-admin, but this ticket is specifically about the release candidates and our automation.

We:

• restrict the versions (only specific GAreleases) that can be chosen for customer environments

• when the assertion fails in a customer environment we force the latest acceptable version

• allow dev users to bypass the restrictions

• when a feature branch is chosen ((pmm_install_version.startswith("PR-"))), deploy server from PerconaLab and a tarball download for the client

• when a release candidate is chosen (pmm_install_version.endswith("-rc")), deploy server from PerconaLab and temporarily enable the experimental repo for the client

In addition, we detect when upgrades/downgrades are necessary, where configuration changes and also where there seems to be a problem; the latter is attempted to be fixed for some known issues

All of this makes the automation code complex, but required so that automation can handle most cases and only make changes where necessary.

Using -rc for one and not for another is an issue as any task that relies on certain conditions means that right now, an RC version is indistinguishable from a release version when deploying OS packages

https://jira.percona.com/browse/PMM-7939      I found root cause and going to fix

 this is good catch!  seems we need to fix this