Comments (2)
I agree with multiple, nearly all, points you've made, but let me elaborate anyway.
…some unintended ABI updates may leak into a release.
I agree and that's why I don't envision this being the default anytime soon. I feel like enabling this mode would need thorough consideration and understanding of the potential implications by the implementer. I'm not sure how to warn users sufficiently and if you have any ideas, I'm willing to include them into my PR.
That said I feel like the potential user is a sane person who knows what they are doing, therefore considering the implications based on the mode they have explicitly enabled is out of the question. In other words: I don't believe the user is stupid.
This means that developers who are willing to use incremental validation have to opt for it explicitly and should be informed about potential risks.
I'd cave into giving them suggestion on a good workflow and to advise that branch protections with sufficient checks and automation are absolute must when using this particular mode. But then again I want to believe most of them use this already.
I'm considering this a good workflow and would love to know your opinion about it:
- PR is opened with new changes
- API is checked for compatibility, PASS
- Reviewer requests changes
- API is changed, pushed
- API is checked for compatibility, PASS
- PR is approved
- API is dumped, committed and merged
It's no longer the plugin's responsibility…
I feel like we have a misunderstanding regarding the responsibilities here. From my point of view, in the current state the plugin is that it's responsible for failing on every single change, therefore it does not verify the compatibility, it verifies the identity. The compatibility responsibility is deferred to the developer which might or might not have the understanding of this particular plugin and how to make the correct decision about the API being compatible.
My intention is to shift this responsibility to the party which understands these changes and make a correct decision for them. We can discuss how to improve this decision-making process, but I would prefer to do this after user feedback due to obvious reasons.
…incremental validation will probably make the overall release process more complex.
I agree, but not in terms of the developer workflow, but the devops team. I'd love to trade in 1 person's afternoon for the team of 30 saving 15 minutes on every PR. Would you not?
In any case, these are great points and thanks for voicing them 👌
from binary-compatibility-validator.
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,
.api
was 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.api
being 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.
from binary-compatibility-validator.
Related Issues (20)
- BCV Gradle Plugin should not depend on kotlin-compiler-embeddable HOT 1
- BCV tasks do not work for a project with generated sources when configuration cache is enabled
- org.gradle.api.InvalidUserDataException? HOT 2
- @JvmOverloads doesn't generate different methods for compose functions HOT 2
- Klib validation DSL for Groovy is different HOT 1
- Removal of default parameter is binary compatible but breaks runtime HOT 3
- `public` members of non-API supertype should be visible in the inheritor
- Unknown native target errors with Kotlin 2.0.0-RC1 HOT 4
- `KlibSignatureVersion.LATEST.toString()` is rendered as `KlibSignatureVersion(-2147483648)`
- Add Gradle version compatibility tests HOT 2
- Consider moving BCV to Kotlin repo HOT 3
- Description of a Syncs API task is uninformative HOT 1
- Add brief description to the top of .api dumps, to help explain the file and BCV
- Remove case-insensitive dump file names handling logic HOT 16
- Merge JVM and KLib ABI dumps into a single file
- Use a project/module-agnostic name for dump files
- Removing native targets did not cause API check to fail HOT 4
- Support Multi-Release JAR Files HOT 9
- allow apiDumpDirectory outside projectDir if inside rootProjectDi
- Allow `apiCheck` to run on all subprojects before failing HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from binary-compatibility-validator.