Git branching policy

[Pat Ferrel]

I have changes in the master that are needed for some users of Mahout. However the master is often chaotic due to being the branch that is the SNAPSHOT of all partial or not well tested changes. The key feature of the branching model described in the blog is that master is stable and contains only the last release and fixes of features considered critical to users. The SNAPSHOT is in a branch called “develop". We have used this method in PredictionIO for years and it is quite nice. The older method used in Mahout leaves me in the situation of recommending that users pull a specific commit rather than the master. With this new model we would be able to tag and rename artifacts and any pull from master should be far more stable than it is now.

I’d like to propose we use this model for future development. The primary difference would be that the current master would become “develop” and the master would contain the last stable release plus any “hotfix”es. The changes I made to support a user would be proposed for inclusion in the “hiotfix” branch and merged with master and develop. Master would get a tag and perhaps new artifact name like 0.12.2-hotfix.1 and would be documented as a source only “hotfix” it would not require a full maven-verse binary release. The benefit to all users is a stable master and a way to get changes in a sane way with reliable artifact names.

http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>

Thoughts?

[Dmitriy Lyubimov]

we work with much simpler PR model which i don't think fits this very well.

i take it PRs will have to be the "feature" branches and will have to be
posted against that develop branch instead of the master. This will
complicate things unnecessarily IMO. It probably is ok model for tightly
knit teams but for OS i would keep things very simple, i.e., what github
already does.

in other words we only manage master, PRs and minor release branches.

For new features, which is the majority, we don't care how devs come up
with the PRs and we merge them to master, which is really our accumulator
for the next major release.

for hot fixes, we PR them against master as well; but we merge them to both
master and release branch for the next minor hot fix.

at least that's how majority of apache projects on github handle that afaik.

Crucial point is to always PR against the master rather than some obscure
special label. It would be very difficult to work with contributors in any
other way than forking off master -- PR against master cycle.

Post by Pat Ferrel
I have changes in the master that are needed for some users of Mahout.
However the master is often chaotic due to being the branch that is the
SNAPSHOT of all partial or not well tested changes. The key feature of the
branching model described in the blog is that master is stable and contains
only the last release and fixes of features considered critical to users.
The SNAPSHOT is in a branch called “develop". We have used this method in
PredictionIO for years and it is quite nice. The older method used in
Mahout leaves me in the situation of recommending that users pull a
specific commit rather than the master. With this new model we would be
able to tag and rename artifacts and any pull from master should be far
more stable than it is now.
I’d like to propose we use this model for future development. The primary
difference would be that the current master would become “develop” and the
master would contain the last stable release plus any “hotfix”es. The
changes I made to support a user would be proposed for inclusion in the
“hiotfix” branch and merged with master and develop. Master would get a tag
and perhaps new artifact name like 0.12.2-hotfix.1 and would be documented
as a source only “hotfix” it would not require a full maven-verse binary
release. The benefit to all users is a stable master and a way to get
changes in a sane way with reliable artifact names.
http://nvie.com/posts/a-successful-git-branching-model/ <
http://nvie.com/posts/a-successful-git-branching-model/>
Thoughts?