Hello Denis, On Nov 8, 2013, at 16:55 , Denis Ovsienko wrote:
> List, > > I have difficulty understanding the workings of a freshly cloned pdns.git > repository. In particular, the recent release tags exist and look fine: > > $ git tag -l -n10 > [...] > rec-3.5.1 tag recursor 3.5.1 > rec-3.5.2 tag recursor 3.5.2 > rec-3.5.3 tag recursor 3.5.3 > > I would like to study the branch that these tags belong to, but cannot > indentify it. For example, the tag rec-3.5.3 stands for commit c730220, which > doesn't belong to any existing branch. According to the gitk tool, commit > c730220 is preceded by history that includes rec-3.5.1, rec-3.5.2 and > rec-3.5.3 and dates back to 2002 in a strictly linear way. This looks like a > stable release-only branch managed with cherry-picks, except it has no name > and isn't merged into any of the existing branches. > > Could anyone tell if this is the intended effect and what is the current > release workflow of pdns? Thank you. Yes, this is the intended effect (but suggestions are welcome - we are still finding our way around the powerhouse that is git). When we release minor versions (like 3.5.1-3.5.3), this is our process (described based on 3.5.3): - create a branch rel/rec-3.5.3 off of the rec-3.5.2 tag - cherry-pick stuff onto it - test test test - tag rec-3.5.3 - drop branch (as the head is identical to the new tag) We sometimes merge release branches back, but when they consist only of cherry picks of stuff that's on master already, I don't see the point. Major releases, especially for auth, tend to be tags directly on master to begin with. Kind regards, -- Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pdns-dev mailing list Pdns-dev@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-dev
