-----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 For git, I think we should follow the Gitflow Workflow. This would involve maintaining a development branch on which developers would create branches for any development work, with the branches having a name related to the feature and an associated JIRA issue - something like VCL123-some_new_feature. Once development is complete in the branch, the developer either goes ahead and merges it into the main development branch, or if the developer wants feedback first, a pull request can be done before merging it in. Then, the developer would merge the branch in after handling any suggestions/edits from others. At release time, we create a release branch, and tag it each time an RC is released. Any bugs found are fixed in the release branch and also merged into the main development branch. Once a vote is successful, the release branch is merged into the master branch, a tag is created, and the release artifact is generated from that. (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 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. Here is a link for more reading on Gitflow: http://nvie.com/posts/a-successful-git-branching-model/ How does this sound? Josh On Monday, June 22, 2015 3:41:08 PM you wrote: > - gpg control packet > After reading over the link Akkaash sent and doing a little more research, I > think we'd be okay with the "Feature Branch Workflow". However, if we > really want to get structured, we could move up to the "Gitflow Workflow". > > It seems like the Feature Branch Workflow is really similar to how we > currently work with subversion, except that with subversion, our "branches" > are just our local working copies. When I have something to work on, I make > sure my local copy is up to date, then do the work, then commit it back to > trunk. If changes have been made in trunk to the files I'm committing, I > have to merge those changes in to my local copy before I can do the commit. > With git, we'd actually be creating branches for doing work, which would > definitely provide some great benefits, but I feel like the workflow would > be really similar. > > Josh > > On Wednesday, June 10, 2015 11:03:51 AM Andy Kurth wrote: > > On Tue, Jun 9, 2015 at 1:47 PM, Mark Gardner <[email protected]> wrote: > > > Switching to git (well DVCS of any kind) from subversion will require us > > > to > > > have a discussion of workflow as there was only one way to work with > > > subversion but git is more of a version control toolkit (even more than > > > other DVCS tools). Workflow will be where people will feel most lost > > > right > > > after the change. > > > > > > Mark > > > -- > > > Mark Gardner > > > -- > > > > Good point Mark. It is not appropriate at this point to have a vote or > > make a request to infrastructure. It would be helpful if the workflow was > > discussed/planned/documented before switching. This would be very > > beneficial for both committers and non-committers. > > > > The link Akkaash sent is a good starting point. I haven't worked much > > with > > git so this is helpful. Things I'd like to be worked out and documented > > (actual git commands should be included for all of these): > > -General development workflow for committers > > -Workflow for non-committers who are interested in contributing > > code/patches -Workflow for creating a release > > -How to handle major vs. minor/bugfix releases > > > > On a related note, migrating to git affects how we plan for the next > > release. We never created a post-2.4.2 bugfix branch in subversion and > > some commits have been made to trunk which should have probably been > > mirrored into a bugfix branch. We need to decide how to handle this. > > Should we create a bugfix branch in subversion from the 2.4.2 tag before > > the migration to git and apply changes made to trunk, or work this out > > after migrating? > > > > -Andy > > -- > ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWNrKIACgkQV/LQcNdtPQOArQCfZjwzJ6R/OpNq8W/LcmThfuOJ pqQAnRF2G0bgGy2FYRGCiQPwGWMBgIb+ =ULHv -----END PGP SIGNATURE-----
