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
>>
