New Development Workflow: The One True Branch

[shelhamer]

Caffe will switch to a one branch development workflow to reduce friction and confusion. All development will branch from and merge to master. Tags will mark releases. Official feature branches will host radical or involved changes to not block routine development and releases.

• no overhead for core developers handling back-merges and release merges
• no confusion about where to contribute PRs
• release tagging still gives stable checkpoints for downstream

Historically Caffe development has followed a master (stable) and dev (unstable) branch model. This lets research live at the bleeding edge in dev while applications stem from master. Experimental ideas can be tried out in dev, hammered out, then bundled into release merges to master. This isn't sustainable.

Of course master and dev need to be reconciled to found the one branch workflow. This should be accomplished with the next release, which will be soon. Open PRs can still be checked out and merged. We're still deciding how and when exactly to coordinate all this.

[shelhamer]

It turns out our comrades in open source on pylearn-dev are likewise discussing their development workflow but they are considering the switch to the two branch workflow.

There's no cure-all to scientific open source development.

[longjon]

From skimming the pylearn-dev thread, the main source of tension there seems to be between interface stability and ability to rearchitect. In this regard, Caffe may be better off, as its external interface is smaller.

Although it's not entirely clear what all constitutes Caffe's external interface, the core part is certainly the net definition through protobuf, a rigidly structured language. So far we've been able to provide an (automatic) upgrade path for all changes to that interface. We've also not been shy about changing arguably internal interfaces such as C++ method types. So, I think our situation is a bit nicer than theirs for a single-branch model, and it's probably a good idea to consider keeping our interface small in the future.

[shelhamer]

Carried out in #1849 and #1887.