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
