Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix version logic when bumping major version #38595

Merged
merged 4 commits into from
Feb 8, 2019

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Feb 8, 2019

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)

Backport of: #38593
Partial Backport of: #38513

Co-authored-by: Jason Tedor jason@tedor.me

tvernum and others added 3 commits February 8, 2019 14:09
Backported from: fdf6b3f

Co-authored-by: Jason Tedor <jason@tedor.me>
Co-authored-by: Tim Vernum <tim@adjective.org>
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.
@tvernum tvernum added >non-issue :Delivery/Build Build or test infrastructure v7.0.0 labels Feb 8, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@tvernum
Copy link
Contributor Author

tvernum commented Feb 8, 2019

This doesn't work because there's no way to know to tell the difference between these 2 situations:

  1. current=8.0.0 , unreleased=[ 7.1.0 on 7.x , 7.0.0 on `7.0' ]
  2. current=7.0.0 , unreleased=[ 6.7.0 on 6.7 , 6.6.1 on `6.6' ]

The fact that 6.7 is the last release in the 6.x line and therefore is on the 6.7 branch is (at this point in the version history) arbitrary. There is no way to know that we don't expect a 6.8.0, while simultaneously expecting that 7.1.0 should be followed by a 7.2.0

I think we just need to put a marker "end-of-6-development" somewhere, and VersionCollection seems as good a place as any.

@tvernum tvernum requested a review from alpar-t February 8, 2019 06:55
Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes LGTM.

Are you sure we don't have to port any of this forward to make sure we don't run into it again ?

@tvernum
Copy link
Contributor Author

tvernum commented Feb 8, 2019

Are you sure we don't have to port any of this forward

For the 7.x series we're good, because once we have a 7.1.0 (or even 7.0.1) we know that we've switched the "most recent released major" from 6.x to 7.x and that means the last minor of 6.x must be a maintence branch with an explicit branch name.

We will need to work out what solution we want for this when we hit the end of 7.x development, because, assuming our process is the same, that will have exactly problem of (for argument's sake) 7.8 is last minor in 7.x, but how does the 8.0.0 build know that there won't be a 7.9 ?

But I'm not sure if this fix is the one we want to copy to master. It's not terrible, but I think it's worth @elastic/es-core-infra discussing it before we do that.

@tvernum tvernum merged commit 558b454 into elastic:7.0 Feb 8, 2019
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Feb 8, 2019
* 7.0:
  Mute IndexFollowingIT.testIndexFallBehind (elastic#38618)
  Mute failing WatchStatusIntegrationTests (elastic#38621)
  Mute failing  ApiKeyIntegTests (elastic#38614)
  Fix the clock resolution to millis in ScheduledEventTests (elastic#38517)
  [DOCS] Add warning about bypassing ML PUT APIs (elastic#38606)
  Fix HistoryIntegrationTests timestamp comparsion (elastic#38566) Backport(elastic#38505)
  Mute RetentionLeastIT.testRetentionLeasesSyncOnRecovery on 7x (elastic#38600)
  Fix version logic when bumping major version (elastic#38595)
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure >non-issue Team:Delivery Meta label for Delivery team v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants