search

robstoll / atrium-roadmap

Contains issues created by the maintainers of Atrium
1 stars 0 forks source link

set up japi-compliance-tester #22

Open robstoll opened 5 years ago

robstoll commented 5 years ago

to check binary backward-compatibility: https://github.com/lvc/japi-compliance-checker

most likely we cannot use it for source compatibility

robstoll commented 4 years ago

another similar tool: https://github.com/siom79/japicmp

jGleitz commented 4 years ago

Are we supporting binary compatibility or not? Because I thought you said you wanted to support it, but then you broke it wtih v0.9.2.

I, personally, do not think binary compatibility is necessary, because I never saw anyone storing their compiled code (except for caching). But we should have clarity on that.

robstoll commented 4 years ago

So far I only guarantee it for the API modules not for domain,core etc. Also, I don't consider changing an experimental feature as breaking change or what exactly do you mean?

jGleitz commented 4 years ago

So far I only guarantee it for the API modules not for domain,core etc.

what is your reasoning here? (a.k.a. “why bother”?)

what exactly do you mean

I ran into the error that expect could not be resolved because it had changed its return type (Expect to RootExpect, return types are part of the signatures in bytecode!). But recompiling solved the problem. I actually expected gradle to recompile the tests in the first place, because a dependency changed, but for some reason it did not.

robstoll commented 4 years ago

I ran into the error that expect could not be resolved because it had changed its return type (Expect to RootExpect, return types are part of the signatures in bytecode!).

Argh... the bcc-tests revealed this issue as well but I flagged it as OK thinking that it only concerns the experimental feature. Must have been quite tired when I released 0.9.2 :sleeping: Anyway... I guess most don't bother if it is binary backward compatible or not

what is your reasoning here? (a.k.a. “why bother”?)

I was involved in a project where tests where actually stored as jar in nexus and only fetched and run. This was done to speed up the CI-pipeline which was already quite slow. But yeah... never had this requirement in any other project.

jGleitz commented 4 years ago

I guess most don't bother if it is binary backward compatible or not

Exactly. I think we should get to an agreement of whether we want to achieve binary compatibility or not. Because it influences what we classify as a breaking change.

I think users don’t need binary compatibility. However, one could make the argument, that third-party libraries need it. Since only one version of atrium is loaded at runtime, we could break third-party libraries.

robstoll commented 4 years ago

Because it influences what we classify as a breaking change.

I would try as good as we can to achieve binary compatibility. I think currently there aren't any third-party extensions for atrium out there. However, once there are, then it would make sense to have binary compatibility as a user of Atrium could then update Atrium to the next minor without the need to upgrade the third-party library as well. I guess that's what you meant as well and IMO that makes the use of Atrium or rather the upgrade to a new version of Atrium more pleasant.

jGleitz commented 4 years ago

Okay!