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
