Re: Looking for advice about json-simple 3 transition
Le 13/05/2020 à 15:46, Gilles Filippini a écrit : > I'd like to push json-simple 3.1.1 into unstable, but I'm not sure how I > should handle the transition. The 3.x releases are not backward > compatible with 2.x. > > A whole set of deprecated classes has been removed: >> * Deprecated JSONParse and JSONValue in favor of Jsoner. >> * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. >> * Deprecated JSONObject in favor of JsonObject. >> * Deprecated JSONArray in favor of JsonArray. Did you consider reintroducing the removed classes? That's the strategy I've adopted for Guava. That's much less hassle than patching the reverse dependencies and handling a transition. Emmanuel Bourg
Re: Looking for advice about json-simple 3 transition
On Thu, 14 May 2020, Gilles Filippini wrote: > I think I could try this indeed. Would a versioned 'Breaks' field > listing the few reverse dependencies be useful then? Yes, it’s pretty much required to ensure that upgrades from the previous release work. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Looking for advice about json-simple 3 transition
mer...@debian.org a écrit le 14/05/2020 à 11:18 : > On 2020-05-14 11:27, Gilles Filippini wrote: >> I think I could try this indeed. Would a versioned 'Breaks' field >> listing the few reverse dependencies be useful then? > > No, this is not needed, libsimple-json-java upload for v3.0.0 shouldn't > be any different from the other uploads. However, please explain the > situation in transition bug report prior to uploading > libsimple-json-java v3.0.0 to unstable. There might be other gotchas, > thus it's better to ask for release team guidance. Ack. Thanks again. _g. signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
On 2020-05-14 11:27, Gilles Filippini wrote: > I think I could try this indeed. Would a versioned 'Breaks' field > listing the few reverse dependencies be useful then? No, this is not needed, libsimple-json-java upload for v3.0.0 shouldn't be any different from the other uploads. However, please explain the situation in transition bug report prior to uploading libsimple-json-java v3.0.0 to unstable. There might be other gotchas, thus it's better to ask for release team guidance. Best, Andrius signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
mer...@debian.org a écrit le 14/05/2020 à 09:56 : > Hello, > > On 2020-05-14 10:07, Gilles Filippini wrote: >> I won't maintain 2 source packages. The deprecated one (version 2.x) >> should be dropped. The 'Conflicts' field is needed during the transition >> only. The new package would have: >> * 'json-simple' as source package name (unchanged) >> * 'libjson-simple3-java' as binary java package name, conflicting with >> previous one 'libjson-simple-java' >> * 'libjson-simple-doc' as documentation package name (unchanged). > > Got it. I assume you need a different binary package name just for the > transition. > > However, this seems avoidable as well. The following Ben tracker seems > sufficient for me: > > Affected: .depends ~ /\blibjson-simple-java\b/ > Good: .depends ~ /\blibjson-simple-java\b/ >= "3.0" > > This way all reverse dependencies will be listed as affected, but only > the ones that explicitly say that they depend on json-simple-java >= 3.0 > will be treated as already migrated ones. I think I could try this indeed. Would a versioned 'Breaks' field listing the few reverse dependencies be useful then? Thanks, _g. signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
Hello, On 2020-05-14 10:07, Gilles Filippini wrote: > I won't maintain 2 source packages. The deprecated one (version 2.x) > should be dropped. The 'Conflicts' field is needed during the transition > only. The new package would have: > * 'json-simple' as source package name (unchanged) > * 'libjson-simple3-java' as binary java package name, conflicting with > previous one 'libjson-simple-java' > * 'libjson-simple-doc' as documentation package name (unchanged). Got it. I assume you need a different binary package name just for the transition. However, this seems avoidable as well. The following Ben tracker seems sufficient for me: Affected: .depends ~ /\blibjson-simple-java\b/ Good: .depends ~ /\blibjson-simple-java\b/ >= "3.0" This way all reverse dependencies will be listed as affected, but only the ones that explicitly say that they depend on json-simple-java >= 3.0 will be treated as already migrated ones. Hope this helps, Andrius signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
mer...@debian.org a écrit le 14/05/2020 à 07:20 : > Hello, > > On 2020-05-13 16:46, Gilles Filippini wrote: >> I'd like to push json-simple 3.1.1 into unstable, but I'm not sure how I >> should handle the transition. The 3.x releases are not backward >> compatible with 2.x. >> >> A whole set of deprecated classes has been removed: >>> * Deprecated JSONParse and JSONValue in favor of Jsoner. >>> * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. >>> * Deprecated JSONObject in favor of JsonObject. >>> * Deprecated JSONArray in favor of JsonArray. > > Maybe it wouldn't be too difficult to patch the dependencies to work > with 3.x release? There are ~15 source packages, so I'd say it should be > doable provided the API changes are not too drastic. This would allow to > retain the same binary package name. Yes, I'm working on patch proposals. But I need this naming issue solved before filing bugs. >> I think about renaming the binary package to libjson-simple1-java but >> keeping the jar file name as json-simple.jar. It implies setting >> Conflicts: libjson-simple-java. > > Name libjson-simple3-java would be better, as it reflects the upstream > version. However, I would recommend against having conflicting JAR > names, as this would effectively forbid coexistence of packages > depending on different versions of json-simple. > > If having both v2 and v3 JARs could not be avoided, I'd suggest > providing /usr/share/java/json-simple-2.x.jar in libjson-simple-java and > /usr/share/java/json-simple-3.x.jar in libjson-simple3-java. Packages > junit [1] and junit4 [2] are made to coexist in a similar manner. > > [1] https://packages.debian.org/sid/all/junit/filelist > [2] https://packages.debian.org/sid/all/junit4/filelist I won't maintain 2 source packages. The deprecated one (version 2.x) should be dropped. The 'Conflicts' field is needed during the transition only. The new package would have: * 'json-simple' as source package name (unchanged) * 'libjson-simple3-java' as binary java package name, conflicting with previous one 'libjson-simple-java' * 'libjson-simple-doc' as documentation package name (unchanged). > Hope this helps, It does. thanks, _g. signature.asc Description: OpenPGP digital signature
Re: Looking for advice about json-simple 3 transition
Hello, On 2020-05-13 16:46, Gilles Filippini wrote: > I'd like to push json-simple 3.1.1 into unstable, but I'm not sure how I > should handle the transition. The 3.x releases are not backward > compatible with 2.x. > > A whole set of deprecated classes has been removed: >> * Deprecated JSONParse and JSONValue in favor of Jsoner. >> * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. >> * Deprecated JSONObject in favor of JsonObject. >> * Deprecated JSONArray in favor of JsonArray. Maybe it wouldn't be too difficult to patch the dependencies to work with 3.x release? There are ~15 source packages, so I'd say it should be doable provided the API changes are not too drastic. This would allow to retain the same binary package name. > I think about renaming the binary package to libjson-simple1-java but > keeping the jar file name as json-simple.jar. It implies setting > Conflicts: libjson-simple-java. Name libjson-simple3-java would be better, as it reflects the upstream version. However, I would recommend against having conflicting JAR names, as this would effectively forbid coexistence of packages depending on different versions of json-simple. If having both v2 and v3 JARs could not be avoided, I'd suggest providing /usr/share/java/json-simple-2.x.jar in libjson-simple-java and /usr/share/java/json-simple-3.x.jar in libjson-simple3-java. Packages junit [1] and junit4 [2] are made to coexist in a similar manner. [1] https://packages.debian.org/sid/all/junit/filelist [2] https://packages.debian.org/sid/all/junit4/filelist Hope this helps, Andrius signature.asc Description: OpenPGP digital signature
