Hi, I think it's easy to single out OAK-7741 as the source of the issues, when in fact the question is really about all the classes affected by the OAK-7511 change. As it stands now, none of them are backportable to 1.8 due to the exact same issues as OAK-7741: the annotation change will trigger a minor bump in the export version making the 2 branches diverge (if applied over other backports that touched the export version).
I think the decision is if we will _never backport_, in which case all is well because the above case will never happen. or _probably backport_ in which case it's a good time as any to begin. This was in fact an happy occurrence where I could rollback my backport and skip this release, and I'm happy it provided the opportunity to give the OAK-7511 backport some more air time. best, alex On Fri, Nov 2, 2018 at 2:35 PM Angela Schreiber <[email protected]> wrote: > 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. >
