On Saturday, 1 de January de 2011 21:57:15 Eike Hein wrote: > Dirk's existing behavior with the KDE SC of tagging a release > branch and then comitting to the tag to merge in additional stuff > will indeed have to change in the future. He's going to have to > retag a point somewhere in the release branch commit chain instead.
Not really, he could do: > Or if there really is a need to cherry-pick stuff from the release > branch but avoid having other changes from that branch in the tag, > that would constitute a distinct fork from the release branch in- > deed. That's essentially what Nicolas' first shot is showing, ex- > cept the breakout commit doesn't actually contain any changes. That's a release branch. We do that in Qt too: http://qt.gitorious.org/qt/qt-releases But not in Qt Creator. Those are short-lived branches, managed by the Release Manager only. He cherry-picks necessary fixes and makes the packages. In Qt's case, the number of changes can be in the order of hundreds. Once a release is made, the RM tags the last commit in that branch, merges it back to the mainline (using strategy "ours") and should delete the branch. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
