search

paultag / crank

2 stars 3 forks source link

debian version can actually break stuff sometimes #13

Open tianon opened 10 years ago

tianon commented 10 years ago

So, right now, if we have a 1.0.0-1 version and then we get a nightly, it'll be something like 1.0.0+10470+23f4904-68~trusty1 (which specifies that debian/ has "67" commits since its last tag). This is all fine, except that if we get a 1.0.0-2 release, our debian version would change to have a lot less than 67 commits since its last tag. It'd be nice if we could somehow reconcile this so that for a -2 debian release, our nightly release version also bumps appropriately.

(Or otherwise somehow figure out a more appropriate "debian version".)

tianon commented 10 years ago

As a much more concrete example of stuff that's actually broken right now, src:docker.io version 1.2.0~dfsg1-1 was finally just now released. Before it was released, https://launchpad.net/~docker-maint/+archive/ubuntu/testing had version 1.2.0+10470+23f4904-68~utopic1 (essentially with our in-progress packaging changes prepping for 1.2.0), which is great. Now that it's released though, there's a new tag, so the version Crank wants to upload is now 1.2.0+10470+23f4904-3~utopic1, which obviously breaks (and @paultag will now start getting emails about rejected uploads, which he's not going to be at all happy about, because Crank has no way to know that there's a higher version number already uploaded).

tianon commented 10 years ago

Maybe instead, we should parse the current "debian version" from debian/changelog, and then use -{debian-version}~git{debian-git-commit-count}, so we'd have something like 1.2.0+10470+23f4904-1~git67~utopic1 before the 1.2.0-1 release, and then 1.2.0+10470+23f4904-2~git1~utopic1 afterwards.

This would fall down when the version is released and then there's no new debian/changelog entry added, but that could be fixed by having Crank notice that the "target" of the latest entry isn't UNRELEASED and automatically adding a +1 to the debian packaging version, so after 1.2.0-1 is released, we automatically get 1.2.0+...-2~git0 due to UNRELEAED becoming unstable (or whatever else, which is why the test would be based on the UNRELEASED string).