Good point. To be clear, what I assumed #2 included moving that JSONUtil class to a separate package.
On Tue, Apr 25, 2017 at 10:02 AM Konrad Windszus <konra...@gmx.de> wrote: > I am also in favour of #2 but I would strongly recommend to put JSONUtil > to a dedicated subpackage. Even in the new version this has a dependency > towards javax.json which may change in the future. If we have to do another > change in the future in that area, this would only affect the package with > the JSONUtil but not e.g. XSSApi. > > On 25. Apr 2017, at 14:21, Justin Edelson <jus...@justinedelson.com> > wrote: > > > > I think #2 is the best option of these and I can't see another reasonable > > path forward. > > > > Regards, > > Justin > > > > On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler <cziege...@apache.org> > > 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? > >> > >> I think we should definitely not do 1) > >> > >> Carsten > >> > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> cziege...@apache.org > >> > >
