Hi Marcel That sounds reasonable to me.
Kind regards Angela ________________________________ From: Marcel Reutegger <[email protected]> Sent: Monday, December 9, 2019 2:15 PM To: [email protected] <[email protected]> Subject: Re: Deprecating API signatures referring to Guava in 1.10 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). Regards Marcel
