Riccardo Mottola wrote: > Yavor, could you explain the soname requirement?
Sure. When the SONAME is bumped, at least one binary package name changes: src:gnustep-base builds bin:libgnustep-base1.30 now but that will change to bin:libgnustep-base1.31 (presumably). When a binary package is renamed or a new one is added, the upload must be manually approved by the Debian FTP masters so it must pass trhough the so called NEW queue: https://ftp-master.debian.org/new.html We can't predict how long the package will be stuck there as we have no control whatsoever (fisicalab.app has been there for 3 months, and gshisen.app for 5 days -- and we don't know when they'll be accepted or rejected). We also need extra time to build-test the reverse dependencies against the new library version so that we can send a library transition request to the release team, notifying them which packages fail to build. So this timeline (the transition deadline minus one month) is a very rough estimate, it could be insufficient (as proved in the previous cycle when the upstream releases were made in time) or it could be 3 weeks or even less if things go well. > I was thinking about this proceeding: kick out stuff with a soname > bump (e.g. AddressesView 0.50.0) quickly, Then work out smore more > fixes provided they don't change API and thus get e.g get out > 0.50.1. It is not our standard proceedings, but it might be a good > idea this time, if it is feasible. > This would buy us another month, right? Right, this is fine. I think the release team won't like it if we combine a major GNUstep library transition with an Addresses transition as this will require at least one extra sourceful upload. But it's certainly doable.
