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?
Kind regards Angela ________________________________ From: Julian Reschke <[email protected]> Sent: Thursday, December 5, 2019 1:30 PM To: [email protected] <[email protected]> Subject: Deprecating API signatures referring to Guava in 1.10 Hi there, see <https://issues.apache.org/jira/browse/OAK-7182>. In trunk, we now have deprecated all API signatures that used Guava objects. I'd like to gradually backport these changes to 1.10, but this will be tricky due to the semantic versioning of the APIs. For instance, changes in oak-commons will require backporting all interim changes that went into trunk since we branched 1.10. The first one would be OAK-8018. This is not high priority, but then, if we want to make a breaking change in trunk, we should actually have deprecations and replacements in place in 1.10. I'll post "Intent to backport" messages for the individual changes as I get to them. Feedback appreciated, Julian
