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
