Thanks for your replies. I guess, that switching the namespace leads to binary incompatibility (If I take the definition from [1]). I cannot drop it in a running JVM / app and expect no issues with it as the related APIs are breaking namespace changes (at least at runtime if they aren't present) :-)
Aside from that fact, method signatures might also change from javax -> jakarta, which would require a short investigation and usage of the existing tooling to see if this happens. From a commons point of view that would mean to go for dbcp3, right? Gruß Richard [1] https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas <ma...@apache.org>: >On 16/12/2022 13:24, Gary Gregory wrote: >> Thank you Richard for starting this thread. >> >> My view is simpler perhaps: I would not make this about the javax vs >> Jakarta namespaces. >> >> I don't want to double the numbers of jars we produce from the same branch >> for affected components as one of the scheme proposed. It feels like a >> burden to maintenance moving forward and a very brittle process with some >> unforeseen side effects. >> >> This is just a code change IMO. For a given component, either it is binary >> compatible, or it is not. You don't know until you try it and see if public >> and protected elements break, using our existing configuration of Maven and >> japicmp (or revapi). >> >> If it is binary compatible, then let's consider making the change. If not, >> then do it in a major version, where the previous major version is >> maintained as we do now, as need be. >> >> A new major version also benefits from the usual dropping of deprecated >> elements and making any other changes with seem reasonable. > >+1. I don't see this as any different to increasing the minimum version of >Java and supported new JDBC methods. > >Mark > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org >
