On Nov 02, 2015, at 11:07 PM, Sandro Tosi wrote: >I dont think I follow your description: looking at the debian repo, stable >has 1.5.6-5 while testing and unstable has 1.5.6-7; looking at the git repo >(as of http://anonscm.debian.org/cgit/python-modules/packages/python-pip.git) >all the branches are from 5 months ago except for master which is 3 weeks >old. so how do you make it work?
So I'll preface this by saying I suck. I should really adopt the DEP-14 conventions so it's less confusing *and* document this in d/README.source. release-1.5.6 is for uploads to unstable and the last push three months ago on that branch was for 1.5.6-7. master is for what will be the new upstream whenever I get more time to work on it. release-1.5.6 branch is at least correct: http://anonscm.debian.org/cgit/python-modules/packages/python-pip.git/tree/debian/changelog?h=release-1.5.6 So it's not completely analogous to your case; I just wanted to point out that you can have whatever branches you want for other releases, and git-dpm should continue to Just Work. >say I have v1.0 packaged in master for unstable, and want to package >v2.0 for experimental: should I created a release-2.0 (and a relative >upstream-release-2.0 (what are the commands to obtain it, btw?)) and >then doing the exp packaging there? how do I manage when I want to >upload v2.0 to unstable? merge release-2.0 to master, >upstream-release-2.0 to upstream? what if then I want to backport a >previous revision of 1.0 to jessie? > >they might seem rare situations, but I face them everyday doing >backports for work and wanting to upload them to debian as well. Raphael can probably say more about this, and advocate for DEP-14, which in your case probably makes more sense than I have: http://dep.debian.net/deps/dep14/ It's probably worth some experimentation to see if DEP-14 is the right approach for you, and how that might inform updates to DPMT policy at some point. Just remember to document it in README.source. ;) trying-to-be-less-unhelpful-ly y'rs, -Barry