On 10/04/2020 15.50, Julian Reschke wrote:
On 10.04.2020 14:31, Ate Douma wrote:
Hmm, I now see there was some (very minimal) 'discussion' about this,
which I missed.
It might have been more helpful and effective (to trigger me) with a
more descriptive subject for that discussion ...
Anyhow, I agree there might not be much *technical* reasons to keep
maintaining 2.18, while 2.20 is almost the same.
But to be clear, 2.18.5 actually is *more* up to date than 2.20.0
with respect to 3rd party dependencies (including security related
fixes).
For us 2.18.x therefore *is* the leading jackrabbit version, still.
There will always be cases in which the release schedule can lead to a
dependency update showing up in a "lower" version first; that's for the
simple reason it didn't make sense to delay it further.
As we do not embed these dependencies (except in demo projects), this is
really not critical. Users of Jackrabbit should always make sure that
the non-Jackrabbit code they use it up-to-date.
So before marking 2.18 EOL I would strongly recommend (request) that
first a more up-to-date 2.20 is released.
...and if you look closely at downloads page, you will see that releases
from the latest stable branch (right now 2.20) indeed happen more
frequently than those from older maintenance branches. So there really
is no basis to worry about that.
And give downstream users (not on oak or from adobe) an appropriate
heads-up and time to catchup :-)
If you look at
<http://jackrabbit.apache.org/jcr/jackrabbit-roadmap.html>, you will see
that the EOL is currently scheduled for autumn.
Right. I was responding to the description of the JCR-4552 ticket, and
that doesn't give any timeline or indication.
It just surprised me as that there was so little discussion on this
change, nor timeline indication on the *list*.
For us, the forced upgrade from v2.18 to v2.20 is technically trivial,
as indeed to *code* didn't really change.
But the move of jackrabbit-api to oak-jackrabbit-api has some more
impact for (our) downstream developers who now will have to change those
*coordinates*.
Which is a trivial change too, but still has impact for customers under
a maintenance contract.
That was already a known consequence of upgrading to 2.20, but without
much impact as long as jackrabbit 2.18 had the 'normal' maintenance
lifespan of a few more years ahead.
With the now drastically shorted lifespan for 2.18, that changed.
We'll deal with it, no problem, but it is rather unexpected.
Regards, Ate
Best regards, Julian
