GitHub Branching Model.... about stormwater-management-model HOT 8 CLOSED

@bemcdonnell and @goanpeca GitHub is complicated for the uninitiated developer regardless of the branching model adopted by the project. If the branching model adopted is not documented then of course there will be confusion. That said, you are doing the work, so you get to choose the branching model. I would recommend documenting it.

I am committed to working here at OWA, but the headache of keeping track of the US EPA repo isn't going to go away. You need to accommodate it in your plans.

OR we can use the name develop instead of master if this makes the model clearer.

I think what @goanpeca proposes above is a hybrid solution. Basically, do what you want to do, just do it on develop instead of master. That will leave master free for the bothersome tracking of the EPA's repo. I second @goanpeca idea. That sounds like a solution to me.

from stormwater-management-model.

I agree with @bemcdonnell, the current model is leading and will lead to more issues (plus we don't have anything documented!) the usual model is:

master: keeps the latest developments (5.2.0 in this case)
named branches: are kept for stable releases that need patching, e.g. 5.1.x would be such branch.

When we make the first 5.2 release we will create a new branch 5.2.x and do patch fixes there and so on and so on. Any fixes on lower versions (if still supported) are bubbled up to master to keep everything in sync, so if there is a hotfix (patch) on 5.1.17... those changes would be merged against 5.1.x, then on 5.2.x we would merged with 5.1.x to capture those fixes (and solve any merge conflicts) then on master we would merge with 5.2.x and fix any conflicts. This way everything remains in sync from bottom to top.

So all the toolkit effort should actually be going to master and we should have a new branch for patches on 5.1.x release.

The added headache is keeping track of the USEAP repo, but if we need to keep track of that, we should use a branch different from master (if the original idea was to use master for that).

And I suggest we stop using the branch dev. The dev/develop branches make more sense when developing a SAS cause we have alpha, beta and production instances. This is clearly not the case here. OR we can use the name develop instead of master if this makes the model clearer.

from stormwater-management-model.

@goanpeca,

The added headache is keeping track of the USEAP repo, but if we need to keep track of that, we should use a branch different from master (if the original idea was to use master for that)

May no longer be a concern :-)

from stormwater-management-model.

@bemcdonnell @michaeltryby lets have a meeting to settle the workflow a bit more? then we can get it on "paper" :-)

from stormwater-management-model.

i like this one: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

from stormwater-management-model.

i like this one: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

Yeah, that is fine and kinda what we are doing, but we need to incorporate the stable version (current release) branch 5.1.x in this case and 5.2.x in some months

from stormwater-management-model.

@goanpeca and @michaeltryby,

I added a page to the wiki on the Branching Model

from stormwater-management-model.

Oh yes, and I updated the relevant branches. This repo now defaults to the develop branch.

from stormwater-management-model.