fzhinkin
commented
7 months ago I see how useful such a mode could be. However, there are a few concerns worth mentioning.
With a workflow where additions to the .api file don't fail the validation and these changes have to be committed before a release, there are at least two scenarios when things could go wrong:
- if apiDump + commit is fully automated in CI, some unintended ABI updates may leak into a release. Of course, it's all about the review culture in a project and how meticulous reviewers are, but there will be no safety net guarding against such mistakes anymore.
- if, for some reason,
.apiwas not updated before a release, BCV will no longer be capable of warning if some recently added declarations will be later removed (i.e., someone added a public classC, it was released without.apibeing updated, someone later removed classC; since there was no such a class in a dump, BCV won't catch the removal).
This means that developers who are willing to use incremental validation have to opt for it explicitly and should be informed about potential risks.
As a side note:
Therefore it poses a slight deviation from "Regular Workflow", but for a good reason. If the developer works on a gargantuan project, they should not be asked to study the project configuration as they are only responsible for making changes and not breaking compatibility. This is in turn a responsibility of the plugin to verify. In other words their time is better spent studying the current domain, instead of the project build harness.
It's no longer the plugin's responsibility as soon as validation requires some multistep workflow stretched in time and involving multiple cooperating agents to make it work correctly.
While it might seem like a simplification, incremental validation will probably make the overall release process more complex.
diareuse
mikaelstaldal
The Problem
Most of the time the developer wants to know whether the changes done to the project are compatible with the previous version. This is not currently possible due to the hard fail during the
apiCheck(check) phase. It verifies that the API has not changed at all, which loads the developer with more chores and responsibilities, that could be inherently automated.Suggested solution
Introduce a mode in which compatibility validator actually only validates the binary compatibility (not identity) to the previous version. These changes almost exclusively include additions - new methods, new fields, new classes.
Since the compatibility validator already conveniently provides a diff of lines changed, new mode can be introduced to allow searching for removals and in only that case, hard fail the task.
It naturally allows for a workflow which could be similar to following:
Therefore it poses a slight deviation from "Regular Workflow", but for a good reason. If the developer works on a gargantuan project, they should not be asked to study the project configuration as they are only responsible for making changes and not breaking compatibility. This is in turn a responsibility of the plugin to verify. In other words their time is better spent studying the current domain, instead of the project build harness.
Regular Workflow therefore (speculation) proposes isolated instances of different kinds of build/verification instrumentation for each team or module, as the team would have to know instrumentation tasks to essentially not break compatibility if not done automatically. This is what I'd love to avoid.
I submitted a PR #186 which resolves this problem and allows for incrementally compatible checks only.
Obviously there's a plethora of options that could be introduced to the gradle extension to expand this feature to the moon. However to keep the scope for this new feature small, I opted for a simple flag which swaps the internal implementation of the
apiChecktask.