On 27 July 2017 at 02:40, Ximin Luo <infini...@debian.org> wrote: > Russell Sim: > > Hey, > > > > I'm about to do an upload and I was wondering if you thought it would > make > > sense to start shipping this package with a versioned -dev package. At > the > > moment the dev package is un-versioned, and the upstream API can change > > quite significantly with each release. So I'm a bit worried that this > will > > cause package build failures if any rebuilds occur. Does that make sense > > to do this, or is that over complicating things? I couldn't find any > good > > documentation about when it is appropriate to version a dev package. > > > > I won't let this stop me uploading 0.25.1.0, but I'm curious about what > > your opinion is? > > > > Hey, I'd suggest *not* to have the -dev package be versioned. > > Despite the fact that the API changes quite a lot, I would guess that most > (say ballpark 80%) dependants would still build fine with both 0.25 and > 0.26. If you start renaming the -dev packages, you would have to edit the > source code of all of the dependant packages to say Build-Depends: > libgit2-26-dev etc. That is more work than doing binary-only NMU rebuilds, > using the latest version of libgit2-dev. > > Also there would be extra trips through the NEW queue. Also it does not > really help build failures - since you are maintaining 1 source package, if > you upload libgit2-26-dev then the older libgit2-25-dev would go away > anyways and be unavailable for future builds. > > Usually the only appropriate time to do versioned -dev packages is if you > are going to maintain both those versions separately for a long period of > time, and usually this would only be because of very major API changes > (like GTK 2 vs 3) rather than relatively minor changes from 0.25 to 0.26. > > If upstream keeps changing API very significantly then yes, one would have > to make a tradeoff on whether it's more-or-less effort to (a) upgrade > packages to use the newer API or (b) maintain multiple source packages of > these different versions. However, having reviewed the 0.26 release notes, > I think keeping 1 source package (and an unversioned -dev package) is the > better solution for this case. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git >
Thank you for the in depth description it was very helpful. I was thinking the same, but just wanted to clarify. I have tried to upload a new version, but was blocked because of the same FTP ACL as before. I think I should probably look at beginning the DD process. In the meantime it would be great if you could sponsor my upload I have pushed it to git [0]. 0. https://anonscm.debian.org/cgit/collab-maint/libgit2.git/ -- Thanks again, Russell Sim
