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
