Development Process

The Readium SDK team uses the git-flow branch management policy. The ideas are described in this post and summarized here:

master branch

Contains only release code, merged into that branch after each successful release.

develop branch

Used for active development of the next release.

[[feature|git-flow-feature]]/[name] branches

Created from develop to do development of a single new feature (simple changes just go directly into develop).

[[release|git-flow-release]]/[version] branches

Once all required features for a release are implemented in develop, a new release branch is created upon which any remaining bug fixes for that release can happen, allowing concurrent development of other new features against the develop branch. When complete, this branch is merged into both `develop` and `master`, and is tagged.

[[hotfix|git-flow-hotfix]]/[version] branches

Created from master at a release tag when a hotfix must be applied to a prior release. Merged into both master and develop when finished, and tagged for release.

Following the model described above, our development and release procedure uses the following steps:

1. Development of a new version takes place on the develop branch.
2. Each new feature or non-atomic change to a feature is done on a new feature branch created with git flow feature start [name] by a single developer. If more than one developer works on a feature this branch can be pushed to the central repository using git flow feature publish [name] and can be fetched using git flow feature track [name].
3. As features are completed, they are pushed to the central repository for initial QA inspection and sign-off.
4. Once QA has signed-off on a feature branch, its developer uses git flow feature finish [name] to finish that feature branch and commit its changes back into develop. The developer pushes develop back to the central repository.
5. When all planned features for a release have been completed and integrated back into develop, the team lead (currently Jim) creates a release branch using git flow release start [version] and pushes it to the central repository.
6. QA tests the release based on this branch.
7. All bugfixes and other changes requested by QA for this release are made on this release branch. No feature changes will be made for this release.
8. Once the release is signed-off by QA, the team lead will finish the release using git flow release finish [version] and will push the merged develop and master branches to the central repository.

Hotfixes are implemented using a similar process:

1. The team lead creates a new hotfix branch using git flow hotfix start [version] and pushes this to the central repository.
2. ALL development work on the hotfix takes place on this branch, with QA testing at each stage.
3. Once the hotfix has been signed off by QA, the team lead uses git flow hotfix finish [version] to merge it into the develop and master branches, and pushes these to the central repository.