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

ScalaCheck follows semver since 1.14.x #793

Merged
merged 1 commit into from
May 14, 2021
Merged

ScalaCheck follows semver since 1.14.x #793

merged 1 commit into from
May 14, 2021

Conversation

larsrh
Copy link
Contributor

@larsrh larsrh commented Apr 11, 2021

Set PVP to avoid false negatives, as pointed out by @julienrf.

@larsrh
Copy link
Contributor Author

larsrh commented Apr 11, 2021

I'm not actually sure whether the change is correct, so I've started asking around.

@ashawley
Copy link
Contributor

ashawley commented Apr 11, 2021

Is there a policy for MiMa that says "we're binary compatible for downstream Scala libraries but might not always be source compatible with minor versions"? I'm half joking here.

@larsrh
Copy link
Contributor Author

larsrh commented Apr 11, 2021

My concern is not so much about our policy, but rather sbt's interpretation of this attribute. The question is: will sbt yell if 1.13.0 gets evicted by 1.15.4? Those are incompatible, but if we slap "semver" on releases from now on, it might do that.

@ashawley
Copy link
Contributor

So should we wait to enable this in 1.16.0?

@ashawley
Copy link
Contributor

According to https://github.com/scalacenter/sbt-version-policy, we need to add the versionPolicyCheck task to the build.

@ashawley
Copy link
Contributor

Oh, that's an entirely different plugin. Disregard that.

@larsrh
Copy link
Contributor Author

larsrh commented Apr 11, 2021

So should we wait to enable this in 1.16.0?

We might have to wait until 2.0.0, since we switched bincompat policy in the middle of a major version.

@larsrh larsrh marked this pull request as draft April 19, 2021 17:49
@julienrf
Copy link

julienrf commented May 13, 2021

My concern is not so much about our policy, but rather sbt's interpretation of this attribute. The question is: will sbt yell if 1.13.0 gets evicted by 1.15.4? Those are incompatible, but if we slap "semver" on releases from now on, it might do that.

If you declare your versionScheme to be semver-spec, no sbt will not fail if 1.13.0 is evicted by 1.15.4, since the latter is assumed to be backward binary compatible with the former, according to semver-spec.

@larsrh larsrh marked this pull request as ready for review May 14, 2021 11:44
@larsrh larsrh merged commit ddb362f into main May 14, 2021
@larsrh larsrh deleted the topic/semver branch May 14, 2021 12:31
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants