Fix version logic when bumping major version#38593
Conversation
When we are preparing to release a major version the rules around "unreleased" versions and branches get a bit more complex. This change implements the following rules in VersionCollection: - If the tip version on the previous major is a .0 (e.g. 6.7.0) then the tip of the minor before that (e.g. 6.6.1) must be unreleased. (This is because 6.7.0 would be "staged" in preparation for release, but 6.6.1 would be open for bug fixes on the release 6.6.x line) - The "major.x" branch (if it exists) will always point to the latest minor in that series. Anything that is not the latest minor, must therefore be on a the "major.minor" branch For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0, and 7.0.0 must be on the "7.0" branch
If we have versions ... v6.6.0 , v6.6.1 , v6.7.0 , v7.0.0 , v7.1.0 then only v6.6.0 is actually released, the others are all under maintenance/development.
|
I've targeted this to 7.x because that's where the behaviour is needed (it's currently causing the BWC tests to fail), but I will need to backport it to 7.0 and forward port it to master. |
|
elasticsearch-ci/default-distro ./gradlew :qa:full-cluster-restart:v6.6.1#oldClusterTestRunner -Dtests.seed=B7F689F194456ED5 -Dtests.class=org.elasticsearch.upgrades.FullClusterRestartIT -Dtests.method="testSnapshotRestore" -Dtests.security.manager=true -Dtests.locale=es-US -Dtests.timezone=Canada/Pacific -Dtests.distribution=default -Dcompiler.java=11 -Druntime.java=8 This reproduces, but isn't related to this PR, so I will fix it in a separate change. @elasticmachine run elasticsearch-ci/default-distro please. |
|
BWC tests will keep failing until #38594 is merged. |
alpar-t
left a comment
There was a problem hiding this comment.
LGTM thanks for the fix !
When we are preparing to release a major version the rules around "unreleased" versions and branches get a bit more complex. This change implements the following rules: - If the tip version on the previous major is a .0 (e.g. 6.7.0) then the tip of the minor before that (e.g. 6.6.1) must be unreleased. (This is because 6.7.0 would be "staged" in preparation for release, but 6.6.1 would be open for bug fixes on the release 6.6.x line) (in VersionCollection & VersionUtils) - The "major.x" branch (if it exists) will always point to the latest minor in that series. Anything that is not the latest minor, must therefore be on a the "major.minor" branch For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0, and 7.0.0 must be on the "7.0" branch (in VersionCollection) - Special logic so that the 7.0.0 build knows that we do not plan to have any 6.x releases after the 6.7 series Backport of: #38593 Partial Backport of: #38513 Co-authored-by: Jason Tedor <jason@tedor.me>
* 7.x: Make qa/full-cluster-restart tests pass. By fixing a helper method and (elastic#38604) Mute failing WatchStatusIntegrationTests (elastic#38621) Mute failing ApiKeyIntegTests (elastic#38614) [DOCS] Add warning about bypassing ML PUT APIs (elastic#38605) Mute RetentionLeastIT.testRetentionLeasesSyncOnRecovery on 7x (elastic#38597) Only "include_type_name" if running on >= 7 (elastic#38594) Fix version logic when bumping major version (elastic#38593)
While working on a backport I realized that elastic#38593 was merged in `7.x` and missing in master. We need this or it will cause trouble again when we bump majors next time.
When we are preparing to release a major version the rules around
"unreleased" versions and branches get a bit more complex.
This change implements the following rules:
If the tip version on the previous major is a .0 (e.g. 6.7.0) then
the tip of the minor before that (e.g. 6.6.1) must be unreleased.
(This is because 6.7.0 would be "staged" in preparation for release,
but 6.6.1 would be open for bug fixes on the release 6.6.x line)
(in VersionCollection & VersionUtils)
The "major.x" branch (if it exists) will always point to the latest
minor in that series. Anything that is not the latest minor, must
therefore be on a the "major.minor" branch
For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0,
and 7.0.0 must be on the "7.0" branch
(in VersionCollection)