HDF5 Version Numbers and Branch Strategy

Version Numbers

Starting with HDF5 2.0, develop will have a version number equal to the next major release. We will no longer skip odd numbers.

Branch/Tag Strategy

Branches

• develop will continue to be the main development trunk
• v2.x, etc. will be the maintenance branch (like hdf5_1_14)
  • Created just before a major release
  • Kept in sync with develop
  • Only one v#.x branch will be alive at one time
  • No longer maintained when the next release will be a major release (so there will be a 'maintenance holiday' between now and the 2.0.0 release)
• v2.0, v2.1 etc. will be release branches (like hdf5_1_14_5)
  • Created shortly before a release
  • Kept in sync with the parent maintenance branch until the release happens
  • Tags are created from this branch when we release
  • Patch releases will be created by cherry picking bugfixes into this branch and creating a new release tag
  • Can be kept around for posterity

As an alternative to our previous, merge-heavy strategy, where we maintain long-lived branches like hdf5_1_14, we could also move more towards trunk-based development. In this scheme, release branches would be created right off of develop and we'd only create the v2.x, etc. branch when a PR merged a change that required bumping the major version number.

Tags

Tags for released versions will be named v<major>.<minor>.<patch>. We will keep old tags around for posterity, but will also create new tags for all released versions of HDF5 that use the vx.y.z scheme.