On 09.12.2019 14:15, Marcel Reutegger wrote:
Hi,
On 06.12.19, 14:07, "Julian Reschke" <[email protected]> wrote:
once we do a stable release from trunk with the removal (say, 1.26),
there would be no officially supported Oak release which deprecates the
API. That is, 1.10.* (and earlier) would contain the old API (and not
deprecate it), 1.26.0 (and later) would only contain the new API.
I agree that it would be good to have a smooth migration path between
supported releases. But then, backporting changes to a maintenance branch
that are rather enhancements also looks a bit odd to me.
Alternatively, we could declare 1.24 a long term support release and
create a branch at that point. Given our previous discussion around
when to branch, it is something we should consider anyway.
https://jackrabbit.apache.org/oak/docs/release-schedule.html#Branching
Applications on 1.10 using deprecated API would then upgrade to 1.24
first, change the application to use the new API and then finally upgrade
to 1.26 (or whatever more recent that is compatible).
...
That's an interesting suggestion which would achieve that goal.
The downside would be that branching comes with a cost (for future
work), and in this case, it could be avoided.
So the alternatives seem to be:
a) create (and support) a new branch (slightly earlier than we planned to)
b) backport changes that we otherwise probably wouldn't backport
I'll have a look at what *exact* changes would be needed for b)...
Best regards, Julian
