You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2018/11/02 13:11:08 UTC
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.
Re: OAK-7511 (nullability annotations) vs Oak 1.8.*
Posted by Julian Reschke <ju...@gmx.de>.
On 2018-11-06 15:09, Julian Reschke wrote:
> ...
> In the meantime, I realized that also have API changes in trunk that
> predate the annotation change, and which are not in 1.8 - so these would
> potentially also cause version confusion.
>
> Slightly edited output of:
>
>> for i in oak-*; do echo $i; svn diff
>> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.0/$i
>> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.9.6/$i
>> | grep -i "@Version"; done
>
> -snip-
>
> oak-commons
> -@Version("1.0.0")
> +@Version("1.1.0")
> oak-core-spi
> -@Version("3.1.0")
> +@Version("3.2.0")
> -@Version("1.0.0")
> +@Version("1.1.0")
> +@Version("1.0.0")
> -@Version("1.0.0")
> +@Version("1.1.0")
> -@Version("1.0.0")
> +@Version("1.1.0")
> oak-security-spi
> -@Version("3.0.0")
> +@Version("3.1.0")
> -@Version("4.0.0")
> +@Version("4.1.0")
> -@Version("1.5.0")
> +@Version("1.6.0")
> oak-store-composite
> -@Version("0.2.0")
> +@Version("0.3.0")
>
> -snip-
>
> So, unless we backport *all* API changes from trunk to 1.8, *and* do
> that in the right order, we'll have potential version conflicts.
>
> My new proposal is thus:
>
> 1) backport the version annotations to an experimental branch of 1.8
> 2) in trunk, set the baseline comparisonVersion to the version of that
> branch
> 3) see what baseline wants us to change
>
> In the end, we'll probably have to accept that there'll be brokenness in
> the export versions of 1.9.*, and we'll just have to accept that and fix
> it for the next version of 1.9.
>
> ...and, as branching 1.10 is probably not that far away, we better
> should do all of this ASAP.
>
> Best regards, Julian
So I tried this with 1.8.10-SNAPSHOT (no branch yet), and set the
comparisonVersion in trunk accordingly. The baseline check does not
complain; that is, it doesn't ask for version changes.
The reason is pretty clear.
1) If there was (in trunk) a minor version change *before* we changed
the annotations, we'd still be a minor version ahead of 1.8.10-SNAPHOT.
2) If there was (in trunk) a minor version change *after* e we changed
the annotations, we'd still be a minor version ahead of 1.8.10-SNAPHOT.
3) If there were no other changes in trunk, the version number would be
the same as in 1.8.10-SNAPSHOT (correctly).
With that, I propose that I proceed and now backport the nullability
changes to 1.8.
Best regards, Julian
Re: OAK-7511 (nullability annotations) vs Oak 1.8.*
Posted by Julian Reschke <ju...@gmx.de>.
On 2018-11-02 14:11, Julian Reschke wrote:
> 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.
In the meantime, I realized that also have API changes in trunk that
predate the annotation change, and which are not in 1.8 - so these would
potentially also cause version confusion.
Slightly edited output of:
> for i in oak-*; do echo $i; svn diff https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.0/$i https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.9.6/$i | grep -i "@Version"; done
-snip-
oak-commons
-@Version("1.0.0")
+@Version("1.1.0")
oak-core-spi
-@Version("3.1.0")
+@Version("3.2.0")
-@Version("1.0.0")
+@Version("1.1.0")
+@Version("1.0.0")
-@Version("1.0.0")
+@Version("1.1.0")
-@Version("1.0.0")
+@Version("1.1.0")
oak-security-spi
-@Version("3.0.0")
+@Version("3.1.0")
-@Version("4.0.0")
+@Version("4.1.0")
-@Version("1.5.0")
+@Version("1.6.0")
oak-store-composite
-@Version("0.2.0")
+@Version("0.3.0")
-snip-
So, unless we backport *all* API changes from trunk to 1.8, *and* do
that in the right order, we'll have potential version conflicts.
My new proposal is thus:
1) backport the version annotations to an experimental branch of 1.8
2) in trunk, set the baseline comparisonVersion to the version of that
branch
3) see what baseline wants us to change
In the end, we'll probably have to accept that there'll be brokenness in
the export versions of 1.9.*, and we'll just have to accept that and fix
it for the next version of 1.9.
...and, as branching 1.10 is probably not that far away, we better
should do all of this ASAP.
Best regards, Julian
Re: OAK-7511 (nullability annotations) vs Oak 1.8.*
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Alex
I don't want to single out OAK-7741 and I know that there are sometimes compelling reasons to backport even improvements. Just want to avoid future troubles as I experienced it it in the external authentication code base with backports of improvements (one time even ending up with totally different 'states' having the same exported version).
Kind regards
Angela
________________________________________
From: Alex Deparvu <st...@apache.org>
Sent: Friday, November 2, 2018 4:36 PM
To: Oak devs
Subject: Re: OAK-7511 (nullability annotations) vs Oak 1.8.*
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 <an...@adobe.com.invalid>
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 <ju...@gmx.de>
> Sent: Friday, November 2, 2018 2:11 PM
> To: oak-dev@jackrabbit.apache.org
> 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.
>
Re: OAK-7511 (nullability annotations) vs Oak 1.8.*
Posted by Alex Deparvu <st...@apache.org>.
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 <an...@adobe.com.invalid>
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 <ju...@gmx.de>
> Sent: Friday, November 2, 2018 2:11 PM
> To: oak-dev@jackrabbit.apache.org
> 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.
>
Re: OAK-7511 (nullability annotations) vs Oak 1.8.*
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
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 <ju...@gmx.de>
Sent: Friday, November 2, 2018 2:11 PM
To: oak-dev@jackrabbit.apache.org
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.