Reporting mode (PoC available)

[nafg]

Before writing this, I noticed #109, which I guess is related.

However, this is about getting a more detailed report, both from running MiMa and about dependency bumps.

Another difference from #109 is that my goal is not to answer the question, "what is the compatibility status" (e.g. what should my next version bump be), which is important, but that even if it's known, it's still useful to document the exact changes. (The current practice seems to be to document them in the form of temporary MiMa filters, which is clearly suboptimal, to say the least.)

One reason why this difference is relevant is that it doesn't make sense to have to change the versionPolicyIntention. In fact, in my case that would be annoying since I'm actually using versionPolicyIntention to compute my version!

I wrote some code to do this for Slick. You can see my solution here and output here. It's a little hacky though: I had to define a new SBT configuration so I could have an independently-scoped versionPolicyIntention setting, and I had to copy-paste some private code from sbt-version-policy.

If someone wants to adapt it into sbt-version-policy somehow, that would be nice. (Then I could change the Slick PR to just use the new release.) Of course that would not require the separate-configuration hack, it would just be a new task that would call directly into other sbt-version-policy code (which would may or may not have to be refactored a bit).

[julienrf]

If I understand correctly, you would like to have a task that returns a “description” of the problems (a bit like mimFindBinaryIssues) instead of logging everything to the standard output and failing?

[nafg]

Exactly.

Maybe an even better idea is to make a standalone API that's not tied to SBT (so could be used with Mill or other coursier-based tools), layer on top of that an sbt-friendly pure-code API, and make SBT settings and tasks a very thin layer on top of that. At least, that's how I wish all SBT plugins were architecture. ;)

But I guess that's a little out of scope for this use case 😆

[nafg]

Actually I take that back, I forgot what I had meant.

I'm suggesting something more concrete here: copying my code to generate an actual report in markdown. But it could be built on top of the "description" task, which would be useful even if you don't want to add such an opinionated report format task.

[julienrf]

Hi @nafg. I like the idea of introducing a task that returns a report instead of failing. Would you be interested in contributing it? I am not sure about producing markdown reports yet, though. I would start with the “abstract” reports (ie, modeled with Scala data types) and let downstream users interpret these reports as they want (e.g. to produce markdown ones).

I also agree with the idea of making a standalone API that’s not tied to SBT and could be reused by other build tools! Do you mind opening a separate issue for this?

[nafg]

I mean it's already possible to do, as you can see in slick/slick#2356. If you don't want all of that folded in what exactly do you have in mind? Should I even bother making a task, or just refactor to expose a public API that's simpler to use than how I needed to do now? I guess I would have to see what other things it depends on (other than versionPolicyIntention, which I specifically don't want to depend on).

How long do you think it will take? If it should be straightforward I suppose I could try to do it this Sunday G-d willing. (If it will involve a lot of disentangling, or a lot of time until it's merged, I'm not sure I can commit to it right now, and if I merge the Slick PR while in its current state I may lose the motivation, which is to simplify the PR first.)

[nafg]

Part of what I want to achieve is a list of changes, each of them specifying whether they break binary compatibility, source compatibility, both, or none, to the extent that the tooling already "knows" that (via the forward/backward method of approximating that). However, currently both the information from MiMa as well as from the dependency changes of this plugin is in the form of backwards changes and forwards changes. How do I extrapolate from that?

The logic I was using is to say the backward changes are binary-breaking and changes that are listed as being forwards incompatible and not as backwards incompatible are source-breaking. Does that make sense?

[SethTisue]

see also #126