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.
> 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 > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
