If not done in new classes (both can live in the same lib technically), sadly yes.
Le ven. 16 déc. 2022 à 20:14, Richard Zowalla <rich...@zowalla.com> a écrit : > 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 > > >
