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
