I would argue for #2 as well. In regard to the JSONUtil, we should definitely either move it to a different package or delete it completely (see other thread).
regards, Karl On Tue, Apr 25, 2017 at 4:03 PM, Justin Edelson <jus...@justinedelson.com> wrote: > 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 >> >> >> >> -- Karl Pauls karlpa...@gmail.com
