Hi Julian I can't speak for Adobe AEM product management (the product you are referring to) and their release planning for the near future. But I would be surprised if there wasn't a way forward handling potential upgrade issues when it comes to the breaking change in future.
The implications of the java.security.acl.Group deprecation (and ultimate removal in java 14) were pretty limited within Adobe AEM and we might want to get an idea how big the impact on custom code for the Guava story actually is. Wdyt? I remember a few breaking changes with Oak in the past and I don't recall this causing huge disruptions with the AEM code base or with customers code. So, if we can get an assessment regarding the changes at hand, that would for sure also help with the discussion here and with product management. Kind regards Angela ________________________________ From: Julian Reschke <julian.resc...@gmx.de> Sent: Thursday, December 5, 2019 4:12 PM To: Angela Schreiber <anch...@adobe.com>; oak-dev@jackrabbit.apache.org <oak-dev@jackrabbit.apache.org> Subject: Re: Deprecating API signatures referring to Guava in 1.10 On 05.12.2019 16:00, Angela Schreiber wrote: > 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. Yes, but as you know, products based on Oak frequently are based on the latest maintenance branch, not the now quickly moving releases from trunk. People on 1.10.* will not be aware of the deprecation, nor will they have a replacement API to use. (The alternative would be to deprecate but not to include the replacement API; but I would consider that really lame) > 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). Yes, that's a related but different issue. We deprecated these APIs in 1.10, so we're good. > 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 If we can do that, great. Do you have a concrete idea how to achieve that for the product we're both concerned with? > 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. > ... That would be bad. But it's something that can work when done carefully (which is my intent). Best regards, Julian
