Gazebo version numbers are composed of three numbers, such as 1.9.2, that represent MAJOR.MINOR.PATCH
As of Gazebo 2.0.0, each number is incremented according to:
This means all 2.x.x versions will be ABI/API compatible.
''master'': Contains all code that breaks ABI/API compatibility with the current released version
''gazeboX'': Contains code for Gazebo version X, where X is the MAJOR version. Only bugs fixes and features that do not break ABI/API may be submitted to this branch.
All other branches are unstable development branches.
All pull requests must contain an ABI/API compatibility report.
All pull requests to 'gazeboX' must be associated with an issue.
2 or more approvals are required for a pull request to be merged.
As mentioned above, new features cause a bump to the minor version number, and only bug fixes can be included in patch releases. Since there is not always consensus on the distinction between features and bug fixes, we use the following guidelines to decide:
Style / whitespace fixes are not bugs unless they fix the code_check.sh results.
Adding a new test is a feature, not a bug fix.
The steps listed below detail how a Gazebo release is developed. This process is enforced by the core Gazebo team, which currently resides at OSRF.
A set of features and functionality are decided upon. These features are chosen based on public demand, and any contractual obligations. Feature freeze, code freeze, and release dates are also scheduled at this time along with distribution of work to key people.
This is the fun part. The features decided upon in Step 1 are implemented, documentation written, and tests created. All code must pass our tests, static code checking, and be submitted as a pull-request through GitHub.
A branch is created, typically named with the upcoming major.minor number. This branch will eventually become the final Gazebo release. No new features are allowed in this branch from this point on. Only bug fixes will be accepted.
At this point almost all of the major bugs should be ironed out of the release. Other issues should be tracked on the GitHub issue tracker, and documented. Only very critical changes are allowed in the release branch at this time.
A Debian package and source tarball is generated from the release branch. Documentation on the Gazebo website is updated.