Hi Julian On a general note Variant 2) looks better to me. However, looking at OAK-7741 I am not all convinced that this one should have been backported in the first place, because as far as I remember we once decided that we don't backport improvements, didn't we? Specially if the improvement affects public API. But if we really had to backport this one for a compelling reason, wouldn't it be possible to refactor the backport such that it doesn't affect the public API (if i am not mistaken it was just a new constant added, right)?
Kind regards Angela ________________________________________ From: Julian Reschke <[email protected]> Sent: Friday, November 2, 2018 2:11 PM To: [email protected] Subject: OAK-7511 (nullability annotations) vs Oak 1.8.* Hi there, so we made the switch to the Jetbrains annotations in trunk some time ago (July). Doing so required a micro version update, because the annotations are considered part of the API. We now have an issue with the backport for OAK-7741 in 1.8, which would *also* change the version number of an exported package, but the API would be not identical to the one in trunk with the same version number. We discussed this off-list yesterday, and decided to back out the change in 1.8 for now (to unblock a release). Going forward, we need to decide how to proceed. The options seem to be: 1) Review the issue and decide that the version conflict is harmless (and document how we got to that conclusion). This may indeed work, as the conflict is with 1.9.* releases, for which we do not really give stability guarantees. 2) Backport the changes for OAK-7511 to OAK 1.8 (which was so far on hold because it was not clear whether we need it); then re-apply the change. Feedback appreciated, Julian PS: and yes, I volunteer to do the backport of OAK-7511.
