#1200 explain how the branching model will work post 2.5

[macgills]

Fixes #1200
Changes: addition of paragraph to CONTRIBUTING.md

[kelson42]

@macgills I'm against using hotfix for something which is 100% following a normal release process. I don't think we need a special naming for something which is urgent or for a "maintenance release" (in case of develop branch is further to what we want to release in a new minor release. I think this is also this last use case which should be explained here: what happen if we have a set of tickets/fixes we want to release but develop branch is too far ahead? Should we create a develop-x.y.z branch? What will hapen with this branch one time it will be merge to master (should we merge it forward to develop?).

[soloturn]

@macgills i kind of like the concept of "master" and "develop". if it follows the principle that changing the history of master is discouraged or impossible. and changing the history of "develop" as integration branch is allowed. i am against having "feature" and "hotfix" in branch names regulated in a document.

[macgills]

@kelson42 the idea is that we fully map out what development on this project means, ideally we never do any work outside of these 4 contexts. This keeps the branches very neat and we don't end up with trash anywhere on our top directory. Makes it very clear when someone is not adhering to process.
Hotfixes are necessary but hopefully will not be used frequently, it allows for minor functionality updates and usually only when we encounter a crash in the wild, it also allows us to not block development of the next version of the app.

what happen if we have a set of tickets/fixes we want to release but develop branch is to far ahead? Should we create a develop-x.y.z branch? What will hapen with this branch one time it will be merge to master (should we merge it forward to develop?).

I don't quite understand what you are saying here because it just sounds like hotfix to me.

1. We release 3.0 (dev -> master)

2. a crash starts happening on Samsung devices say a week later because we slowly rolled it out

3. dev is too far ahead because of new features that aren't ready yet

4. create a hotfix branch off master hotfix/stupid-samsung-crash

5. do the work of fixing and testing

6. merge hotfix/stupid-samsung-crash -> master and merge hotfix/stupid-samsung-crash -> develop

7. delete the hotfix

If your point is that we want to be in a situation we were in with 2.5 ie We want to release 2.5 but 2.4 was too long ago and all the work was on 3.0, that situation should never ever happen with this structure.
Master is current version, develop is the next version, feature branches can be any version but when they are merged to develop that is our commitment that they are for the next version.