On Wednesday 26 April 2017 14:57:26 Konrad Windszus wrote: > I guess Oliver Lietz meant, changing the symbolic name for the old version > and keep the symbolic name for the new version, but having both bundles as > full-fledged independent bundles. That way the dependencies are easier to > upgrade in the pom.xml.
Sorry for beeing unclear – I really had fragments in mind. O. > > On 26. Apr 2017, at 14:47, Carsten Ziegeler <cziege...@apache.org> wrote: > > > > Oliver Lietz wrote > > > >> On Tuesday 25 April 2017 14:09:51 Carsten Ziegeler wrote: > >>> I'm moving this into a separate thread to make the discussion easier. > >>> > >>> With the current state of the xss module, we would break every consumer > >>> and require her to upgrade code (release their own modules depending on > >>> XSS etc). As xss is pretty popular, this means a high burden on our > >>> downstream users. > >>> > >>> I think we have these options: > >>> 1) Pass on the pain to our users, simply release as 2.0.0 and require > >>> everyone to upgrade > >>> > >>> 2) Release the new api as 2.0 under a different symbolic name allowing > >>> our users to have new and old side by side. In that case we would need > >>> to deprecate 1.x and users should upgrade over time. > >>> > >>> 3) Best effort: we release as 1.x and know that this is an incompatible > >>> change. This will only break users of the old JSONUtil, everyone else > >>> runs without any problems. Unfortunately if others are using the util, > >>> this will only be detected at runtime. > >>> > >>> Are the other/better options? > >> > >> Can we keep the symbolic name for the new bundle and provide an > >> additional > >> compat bundle with old JSONUtil? > > > > No, unfortunately not - the JSONUtil is part of the API package. Although > > it might be possible through a fragment, but I'm unsure what the > > implications are > > (if that works at all). > > > > Regards > > Carsten
