Versioning

Apache Geode can’t really follow Semantic Versioning specification (http://semver.org/)  since even on major releases we don’t break backward compatibility with previous major version. But most principles still apply, such as the model:

...

All changes to the public API must be backwards compatible, with the exception of removing deprecated features. Removing deprecated features also requires discussion. API should be deprecated for a major version before being removed.

Geode supports rolling upgrades on a live system. Message serialization and disk persistence must be backwards compatible with previous versions. This includes algorithmic changes that don't affect the serialization format. Geode has a framework for backwards compatible serialization - see Managing backward-compatibility.

Branching

Apache Geode is heavily based on Git-Flow model [1] and [2] - Based on one of the first threads discussed in the project mailing list.  

The main concepts are:

1) The master branch is reserved for production-ready code, aka releases. 

 No changes are made directly on the master branch.

 Master is merged solely from develop, and only by the "release manager". 

 Merges can only be done, when build is successful on all supported platforms, and the tests on all supported platforms have passed.

2) The develop branch is the development mainline.  Ongoing work shows up here first.

3) Feature branches may be used to isolate interim work and will merge back to develop.

 Public feature branches should only be used, when multiple people work on a feature. A feature branch is started after the intention is made clear on the mailing lists and must be backed by a JIRA ticket.

4) Release branches are created to allow a stabilization period for a release while not impacting ongoing work on develop.  Once a release is stabilized the release branch is merged to master and develop and the release branch shall not be used anymore.

5) Hotfix branches are created for a patch from a release (off master) to support ongoing hot fixes and patches as needed, but after completed MUST be  merged back into both master and develop.   Master should also receive a tag with an updated maintenance version number.

Branch naming pattern:  (?)

- master

- develop

- <feature name>-feature 

- hotfix-<jira#>

- release/vVERSION

[1] http://nvie.com/posts/a-successful-git-branching-model/

[2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow