Team, It's been a few months and we started out with some ideas on how to do things and each of us interpreted that slightly differently. That will continue to be true but we should document these things and keep getting better and more consistent. One area to consider then is the usage of Git and our adherence to the Gitflow [1] workflow as we had discussed.
In my opinion there is little call for us to deal with maintenance branches. So here i am just talking about 'feature branches' and 'release branches'. What I'd propose is that we use what we've learned and provide some better guidance on how to name the branches and the life-cycle of them. For 'feature branches': - Recommend naming them 'NIFI-XYZ[-description]' The [-description] would be optional. But for example this means the 'ListHDFS' branch we have would have been NIFI-553-ListHDFS. - This naming scheme helps people to know precisely which branch that is about and it also promotes cohesive feature branches (that are about a particular JIRA). - Once the feature is complete and has been reviewed it can then be merged into develop - It isn't clear to me when it is the right time to clean up these branches. In my mind it seems like once the feature branch has been merged to develop and part of a release then the feature branch can be removed. It isn't necessary for Git itself to do this but seems like good housekeeping. For 'release branches' - Recommend naming them 'release-nifi-X.Y.Z'. - This release branch would live on forever. When generating an RC it should branch from that release branch. This way as RC's may come and go we're not polluting the commit history. - Once a given RC is accepted it can be merged back to the release branch, master, and develop - This extra sub-branch for the RC sounds a bit like overkill. But it exists to ensure that we do not pollute the commit history of the release and beyond but also to ensure the community can keep progressing with the develop branch. - If for any reason we had to do an emergency type patch to a release or whatnot we could do so with this branch and/or we can use the tag which gets generated during the release process. There needs to be more discussion around the entire lifecycle of contribution of code that considers all roles of the community including those submitting PRs from Github. But this initial note is just to get some consistency and open up for discussion. [1] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow Thanks Joe
