Hi Leopold, On 07-04-2025 23:24, Leopold Palomo-Avellaneda wrote:
I'm the main in charge of the package ompl [1]. The package has a library but no package outside the sources use it.
Right, so this doesn't need a transition.
In December, it was a Team upload with a new upstream version. Last week, trying to resolve a bug I realize that the ABI changed in number but that change didn't was reflected in the package name (libompl16t64 - > libompl17 , I guess). And I think that that violates policy.
I assume that what you mean with "ABI changed in number" you mean that the SONAME bumped and/or that the ABI broke between the two versions of the package. This is indeed covered by the first paragraph of 8.1 [3].
My question is, before Milestone 2 - Soft Freeze 1) Can I push[2] a new version, renaming libompl16t64 to libompl17?
The window to get new packages (be it source or binary) into testing is closing on 15 April 2025. So you'd need to be quick, the package would need to have a successful autopkgtest (to get the time bounty) and have ftp-master process the package very quickly. It's not impossible but I fear you are too late. If you're asking for an exception (fixing a policy violation seems like a good reason), please file a bug against the release.debian.org pseudo package.
2) Today, Upstream has published a new version (1.7.0). Can I try to push it before Milestone 2?
If you are going the exception route, I suggest to hold that off at first. I suggest the following (some parallel) steps, which should happen soon:
1) get your new binary package into experimental at the current version 1) file an exception request 2) upload to unstable if/when the exception is granted 3) ensure migration happens4) (optionally) improve the package in line with the freeze policy of that moment.
Paul[3] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature