On Fri, Jun 26, 2015 at 3:48 PM, Josh Thompson <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's what I suggest: > > 1) Go ahead and create a branch for a bugfix release as 2.4.3 in subversion > from the release-2.4.2 tag > 2) fix any know bugs in 2.4.2, commit the fixes to trunk and the 2.4.3 > branch > 3) release 2.4.3 > 4) migrate to git > This sounds reasonable. [description of the workflow as applied to VCL omitted...] > (I do have a question here - the master branch after the > merge would have to exactly match the release branch, otherwise we > wouldn't be > releasing exactly what was voted on. So, that may need some more > research.) > I can see your concern as we will be voting on a RC branch before it is merged back into the master and tagged. I believe the only concern is if there are any merge conflicts between RC and master. I don't think this can happen since the only time changes occur on master is when the final RC branch is merged by the release manager. I can't think of a situation where the merge onto master would be anything other than what git calls a fast-forward merge that only changes metadata and not VCL code. (Caveat: I am not a git expert.) > I know I've had times when I've been working on a new feature that I > somewhat > have to pull out before commiting work to HEAD leading up to a release. > This > method allows development to continue on such features, but left in a > branch > that doesn't affect the release process. > This is one of the reasons why I am switching all my work over to git. Here is a link for more reading on Gitflow: > > http://nvie.com/posts/a-successful-git-branching-model/ > > How does this sound? > +1 Mark -- Mark Gardner --
