Git Strategy
As of December 2011, the uMobile project is hosted on Github at https://github.com/Jasig/uMobile-app. The project has a limited number of committers, but others are welcome to submit pull requests to the project. When committing or submitting a pull request, it's important that the new features be implemented on the proper git branch. The uMobile project is starting to implement a branching strategy similar to the philosophy and diagram on this page: http://nvie.com/posts/a-successful-git-branching-model/
- The development branch is the branch that's primarily concerned with merging in new features to be available in the next release. New features shouldn't be directly developed on the development branch, but should be merged in from feature-specific branches when they're complete.
- For each new feature to be developed for an upcoming feature release, a branch should be created corresponding to the feature in JIRA. For example, "UMOBILE-221".
- The master branch should only be updated when releases are ready to be tagged as a general availability release. As a rule of thumb, each time a branch is merged into the master branch, it should be tagged as a new version.
- The hotfixes branch is reserved for correcting bugs and issues in the master branch, and should not be used for adding new features.
- For each release candidate, a branch should be created and named as the version number of the upcoming release, eg 1.1.0. Features should only be merged into release branches from the development branch.
For a guide to branching and merging in Git, see http://book.git-scm.com/3_basic_branching_and_merging.html.
Versions and Releases
The version numbering and naming logic is in line with the approach to versioning described on this page under the "Semantic Versioning Specification": http://semver.org/
Essentially, versions should be numbered as Major.Minor.Patch, and should always increment by a value of 1. When a major version increments, the Minor and Patch numbers must reset to 0.