Discussion: Defining a Branch and Release methodology

[cleary]

Hi Adam,
I apologise if you've already got this covered, but I was hoping to discuss/define a Branching/Release methodology for this repository. Since there is currently no other branch than master, I'm assuming it either hasn't been considered, or your usual methodology hasn't been applied yet.

There's a lengthy article on the subject which we recommend here, but given that it's catering to much larger and more complex projects (in terms of number of developers with commit access), I figured that the following proposal would provide a functional model:

• Use two main branches, master and develop
• master is always production ready, so in our case would be the latest release (2.1.8?)
• the state of develop is however you want to define it
• releases should be tagged (git tag), ie every commit to master should increment the release version and another tag should be created. This allows users to switch versions with ease, and is a common method used (for example) by debian/ubuntu package maintainers working with git

What are your thoughts/what have you used in the past for this project?

[ajdonnison]

I have no real issue with the model suggested, although I tend to find that a simpler design with a master branch that is tagged on release and short-lived feature/bug releases works best with smaller projects. So I'm happy to go with whatever the consensus is. I've worked with a number of models as each project tends to already have a workflow in place, including the develop/master model, rebase workflows, master-only model and even more esoteric models. We are lucky at the moment as this is the first release we have used git for in dotProject, so we can choose whatever we want going forward.

[cleary]

Hi Adam,
Sorry this took so long to reply to, I had a pretty busy December and Christmas break, so just revisiting this stuff again now -

I don't have a particularly strong leaning to any particular model, just that there is some model.

My brainstorming - and note that this is approached with my consumer hat on, not my developer hat:
If I want to live dangerously working with non-integration-tested code, staging/dev is my logical choice.
If I want to live safely with bug and security updates as early as possible (without having to wait for an official number incremented dot release) master would be my choice.

Since we're going to be dealing with at least two developers here (yourself, and 2pi guys, plus I see there's some other issues and patches raised) I think the staging/dev branch is a useful model to allow for some integration testing beyond your own during the patch merges before merging into master.
As mentioned, the master branch (in my opinion) should be production ready at all times - whether that means it tracks the latest release only, or it tracks latest release + bug/security fixes, doesn't matter too much to me - but for a project with an existing userbase like dP, I think keeping that master branch squeaky clean is important.

I know you will have dealt with at least two or more version control systems beyond git over the life of the project, and I don't know who else from your development team is potentially going to be working on/committing to the repository - but I understand that that past methods are most likely to determine future methods, but I was hoping to at least discuss the requirements of the different parties (eg ours as a production env consumer) and build a plan that suits all (or most) of them :)

[ajdonnison]

I'vet set up devel as the main development branch - all pull requests should be against this branch. Once we are happy enough to cut a release we will then merge this to master and tag as a new release. Hopefully this achieves all our goals.

[cleary]

Hi Adam,
Works for me 👍