Strengthen MiMa checks #20068
Merged
Strengthen MiMa checks #20068
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nicolasstucki
force-pushed
the
strengthen-mima-checks
branch
from
ee052d7 to
1f7ca72
Compare
Kordyjan
approved these changes
Apr 19, 2024
project/Build.scala
Outdated
Comment on lines
102
to
105
| * This must be the earliest published release in the same versioning line. | ||
| * For example, if the next version is going to be 3.M.4, then this must be | ||
| * set to 3.1.0. If it is going to be 3.1.0, it must be set to the earliest | ||
| * 3.0.x release. |
There was a problem hiding this comment.
This wording is confusing. Is the M a typo in the example? Should the second version be then specified as 3.M.0? Isn't the earliest 3.0.x just 3.0.0?
I suggest including explicit rules in this comment. Something along the lines of:
For a base version `3.M.P` the mimaPreviousDottyVersion should be set to:
* `3.M.0` if P > 0
* `3.(M-1).0` if P = 0
There was a problem hiding this comment.
You are right, it was meant as a 3.M.0.
I will use your version as it is much clearer and direct. I modified it slightly.
Using the latest patch release of the current minor version may lead to some breakages that are not properly checked/tagged in the MiMa filers. For example, if we accidentally introduce a breaking change in 3.M.1 but check against 3.M.2, we would lose this braking change before the next minor release. If we would check against 3.M.0, we would catch this. In general we need to track all the changes that have happened in the current minor version. There should not be any breaking changes unless the PR needs a minor release.
nicolasstucki
force-pushed
the
strengthen-mima-checks
branch
from
1f7ca72 to
72f2da6
Compare
|
I've re-ran the failed tests. It seems to be an inconsequential flake. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using the latest patch release of the current minor version may lead to some breakages that are not properly checked/tagged in the MiMa filers. For example, if we accidentally introduce a breaking change in 3.M.1 but check against 3.M.2, we would lose this breaking change before the next minor release. If we would check against 3.M.0, we would catch this.
In general we need to track all the changes that have happened in the current minor version. There should not be any breaking changes unless the PR needs a minor release.