-
-
Notifications
You must be signed in to change notification settings - Fork 265
HDF5 Version Numbers and Branch Strategy
Starting with HDF5 2.0, develop will have a version number equal to the next major release. We will no longer skip odd numbers.
Going forward, we will try to come as close as possible to trunk-based development. This means that, as often as possible, we will create our release branches off of develop. We will only create a maintenance branch (e.g., v3.x) when breaking changes are made to develop. Unlike our current branch/tag scheme, these maintenance branches should only have a limited lifespan (1-2 releases, not multiple years).
Specifics:
- develop will continue to be the main development trunk
- v2.x, etc. will be the maintenance branch (like hdf5_1_14)
- Only created when breaking changes are merged to develop
- Kept in sync with develop via cherry-picking
- Only one v#.x branch will be alive at one time
- No longer maintained when the next release will be a major release
- v2.0, v2.1 etc. will be release branches (like hdf5_1_14_5)
- Purpose is to provide stability as we prepare the release
- Created shortly before a release
- Not kept in sync with parent branch - just cherry picks of anything important for the release
- 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
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. This will make it easier to check out various versions of the library.