mozilla/pdf.js — Issue #930: Development & Production branches discussion
Author: arturadib
Created: 2011-12-13 16:01:42+00:00
State: open

Now that we have an addon with traditional versioning (0.1.0, 0.1.1, etc), we need to think about how that affects our Github flow and branches.

The two "simplest" options I can think of are:

## 1. Single production branch, many forks (our current)

This is basically our current flow, which coincides with [Github's own flow](http://scottchacon.com/2011/08/31/github-flow.html).

In this simple case development happens in forks/branches outside the master branch, and new code is only merged after review and passing our regression tests. So the branch is always "stable".

Versioning can be introduced by basically decorating the branch with git tags as we publish code out to AMO:

```
o <--- master
|
|
|
o <--- tag: v0.1.1
|
|
o <--- tag: v0.1.0
|
|
|

```

## 2. One production branch, one development branch, one hot fixes branch

This is a simplified version of [git-flow](http://nvie.com/posts/a-successful-git-branching-model/).

In this case experimental code is pushed to a development branch, and occasionally it is merged into the production branch after thorough review, passing all tests, etc.

From time to time, one also pushes code to a "hot-fixes" branch off of a common ancestor between dev and production, which fixes problems with the production branch. Then one merges in hot-fixes into both production and development.

A new version is triggered every time there is a merge into the production branch.

## Discussion

I think Github's fork system, combined with our testing infrastructure which is already tightly integrated with pull requests, naturally makes option #1 both doable and the most convenient.

In principle we would have problems applying hot-fixes to our addon since we would necessarily carry all the previous merges from the master branch. This is typically not desirable in most projects, as such merges might have introduced major features like a new UI, or worse unstable code.

In our particular case this is not a problem: the vast majority of our merges are actually "hot-fixes" (since they essentially fix previously broken PDFs), and in the rare cases of new "features" like a new UI we can simply hold that pull request back until we're ready for a new major release. Also our production branch is always "stable" thanks to the bot and PR review.

Looking forward to the ensuing discussion here...

/cc @wfwalker @jviereck @brendandahl @notmasteryet @ironymark