Sorry for the mess, I've learned that Rich Format is not working for the mailing list. ; o)
This is the message in (hopefully) proper format. Now that all main components of our infrastructure are available, and we are able to start working, I'd like to talk about our git procedure and branching model. I suggest the following branching model: - we adopt the Forking Workflow[1] as the core principal, and - adopt the Gitflow Workflow[2] for ongoing development. Feature branches should be created using the name of the JIRA issue which is to be solved. As our version scheme I'd suggest Semantic Versioning[3]. This would lead to the following branches: - master - hotfix - develop - v1.0.0 - FINERACT-[#] Given the way the Apache framework is working[4], we need to find consensus on how to deal with code modifications and releases. Aside from discussing major changes prior to implementation, some kind of voting is needed. I suggest to use the CTR[5] (commit then review) model for code modifications, and RTC[6] (review then commit) for package releases. We should not mismatch review with a code review. A code review should be done based on the pull request and prior to commit the changes into the main repository. Once this process has finished, a vote based on lazy consensus is initiated with a message like "This solves issue FINERACT-1234, if no-one objects within three days, I'll assume lazy consensus and commit it." What are your thoughts? Best, Markus .::YAGNI likes a DRY KISS::. [1] - https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow [2] - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow [3] - http://semver.org/ [4] - http://www.apache.org/foundation/voting.html [5] - http://www.apache.org/foundation/glossary.html#CommitThenReview [6] - http://www.apache.org/foundation/glossary.html#ReviewThenCommit > From: [email protected] > To: [email protected] > Subject: [DISCUSS] Git procedure and branching model > Date: Thu, 24 Dec 2015 09:25:03 +0100 > > Hey all, > > hope this finds you well. : o) > > Now that all main components of our infrastructure are available, and we are > able to start working, I'd like to talk about our git procedure and branching > model. > > I suggest the following branching model: > > we adopt the Forking Workflow[1] as the core principal, andadopt the Gitflow > Workflow[2] for ongoing development. > > Feature branches should be created using the name of the JIRA issue which is > to be solved. > > > > As our version scheme I'd suggest Semantic Versioning[3]. > > > This would lead to the following branches: > > > masterhotfixdevelopv1.0.0 > FINERACT-[#] > > Given the way the Apache framework is working[4], we need to find consensus > on how to deal with code modifications and releases. Aside from discussing > major changes prior to implementation, some kind of voting is needed. > > > I suggest to use the CTR[5] (commit then review) model for code > modifications, and RTC[6] (review then commit) for package releases. We > should not mismatch review with a code review. A code review should be done > based on the pull request and prior to commit the changes into the main > repository. Once this process has finished, a vote based on lazy consensus is > initiated with a message like "This solves issue FINERACT-1234, if no-one > objects within three > days, I'll assume lazy consensus and commit it." > > > What are your thoughts? > > > > Best, > > Markus > > .::YAGNI likes a DRY KISS::. > > [1] - > https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow > [2] - > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > [3] - http://semver.org/ > [4] - http://www.apache.org/foundation/voting.html > [5] - http://www.apache.org/foundation/glossary.html#CommitThenReview > [6] - http://www.apache.org/foundation/glossary.html#ReviewThenCommit > >
