Hi Julian Sorry, but I still don't get why we have to back port the deprecation plus replacements to 1.10. If we remove the API in Oak 1.26 there are at a whole bunch of official releases between the deprecation/replacement and the release where the breaking change occurs.
I don't recall at which specific version the Guava replacement was introduced, but for the similar java.security.acl.Group issue Alex Deparvu introduced the replacement almost 2 years ago to give consumers an early heads up (back in time when we only had an official release every year). Wouldn't it be better to push for updating upstream applications to use a more recent stable release of Oak? That would already give them the chance to make use of the replacement without us going through the trouble of backporting all those changes? I just see a real risk that we end up with semantic version number in different branches that don't exactly match. Kind regards Angela ________________________________ From: Julian Reschke <[email protected]> Sent: Thursday, December 5, 2019 2:55 PM To: [email protected] <[email protected]>; Angela Schreiber <[email protected]> Subject: Re: Deprecating API signatures referring to Guava in 1.10 On 05.12.2019 13:41, Angela Schreiber wrote: > Hi Julian > > Maybe you could elaborate a bit more about the reasoning of backporting the > deprecated API signatures using Guava 1.10? The reason for the deprecation > was the fact that we want to make breaking changes, right? And this is the > kind of change I would feel quite uncomfortable with when it comes to back > port... when it's just about the deprecation, I am not sure I understand the > bigger benefit of the back port... or do I misunderstand the overall goal > behind this? > ... What I intend to backport are the changes that (a) deprecate the existing API (that uses Guava) *and* (b) introduce replacements. Part (b) is the one that will actually change the API (but in a backward-compatible manner -> minor version change). The reason for backporting to 1.10 is that this is the newest maintenance branch we have. If we actually remove the Guava-based API in a future trunk release (say 1.26.0), people migrating from 1.10.* to that version would be very surprised (and have no supported version to move to first which contains the replacement APIs). Hopefully this clarifies things... Best regards, Julian
