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

Is there a way to specify mimaPreviousArtifacts should include all versions in a range? #483

Closed
jackkoenig opened this issue Mar 11, 2020 · 8 comments

Comments

@jackkoenig
Copy link

For example, I can write something like:

  mimaPreviousArtifacts := {
    val versions = "1.0.0" :: "1.0.1" :: "1.0.2" :: Nil
    Set(versions.map("my.org" %% "proj" % _): _*)
  }

And I tried the following which weirdly worked locally for one project but not another and failed on Travis and CircleCI:

  mimaPreviousArtifacts := Set("my.org" %% "proj" % "1.0.*")

Is the a canonical way to do this or do I just need to include adding additional versions in my release process?

@jackkoenig jackkoenig changed the title Is there a way to specify mimaPreviousArtifacts should include all version in a range? Is there a way to specify mimaPreviousArtifacts should include all versions in a range? Mar 11, 2020
@jackkoenig
Copy link
Author

Perhaps an "inductive" approach is to use + thus new changes will be tested against the prior version, eg.

mimaPreviousArtifacts := Set("my.org" %% "proj" % "1.0.+")

@SethTisue
Copy link
Collaborator

Within a compatible series, it should be adequate to check against any single previous release in that series. It isn’t obvious to me whether it’s “better” to use the oldest in the series or the newest, since it’s hard to see how it could matter.

@dwijnand
Copy link
Collaborator

Newest is better as, otherwise, you risk losing methods added in a.b.1.

Doing this makes the build non-reproducible, so I'm not in favour.

But you could implement this today by invoking Coursier in your build definition, get the versions available and then use those versions to specify mimaPreviousArtifacts (which will be resolved again, by Ivy this time - it doesn't use Coursier, yes).

@SethTisue
Copy link
Collaborator

Newest is better

Oh right, of course. (I’m too accustomed to Scala stdlib’s tighter constraints.)

@jackkoenig
Copy link
Author

Doing this makes the build non-reproducible, so I'm not in favour.

Good point, and it will often mean that old commits no longer pass the MiMa check since they may not be binary compatible with newer versions.

I guess one tricky thing about having it find the prior versions is that you need to be sure you can determine that. We set the version as 1.0-SNAPSHOT in the intermediate versions (for example, between 1.0.1 and 1.0.2) so unless we are careful to keep all prior releases as ancestor commits, this wouldn't work either.

Perhaps the best approach is just updating mimaPreviousArtifacts as part of the release process.

@SethTisue
Copy link
Collaborator

Perhaps the best approach is just updating mimaPreviousArtifacts as part of the release process

(that's what I see most OSS projects doing)

@jackkoenig
Copy link
Author

Thank you both for your help!

@SethTisue
Copy link
Collaborator

further discussion at #724

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants