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.
Dependencies are not based on symbolic name, but on maven coordinates. Carsten > >> On 26. Apr 2017, at 14:47, Carsten Ziegeler <[email protected]> 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 >> [email protected] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
