/** \page BRANCHEXPL HDF5 Git Branching Model Explained

Navigate back: \ref index "Main" / \ref TN
<hr>

This document describes current HDF5 branches. 

Branches are tested nightly and testing results are available at
https://my.cdash.org/index.php?project=HDF5. 
Commits that break daily testing should be fixed by 3:00 pm Central time or reverted.  
We encourage code contributors to check the status of their commits. If you have any questions,
please contact help@hdfgroup.org.
 
\section sec_branchexpl_develop develop branch
Develop is the main branch whose source code always reflects a state with the latest delivered
development changes for the next major release of HDF5. 
This is also considered the integration branch, as \b all new features are integrated into this
branch from respective feature branches. Although
develop is considered an integration branch, it is not an unstable branch. All code merged to
develop is expected to pass all GitHub actions and daily tests.

\section sec_branchexpl_maintenace Maintenance branches
Each currently supported release line of HDF5 (e.g. 1.8.x, 1.10.x, 1.12.x, 1.14.x) has an associated
branch with the name hdf5_1_10, etc.. 
Maintenance branches are similar to the develop branch, except the source code in a maintenance
branch always reflects a state 
with the latest delivered development changes for the next \b maintenance release of that particular
supported release-line of HDF5. 
\b Some new features will be integrated into a release maintenance branch, depending on whether or
not those features can be 
introduced in minor releases.  Maintenance branches are removed when a release-line is retired from
support.

\section sec_branchexpl_release Release branches
Release branches are used to prepare a new production release. They are primarily used to allow for
last minute dotting of i's and crossing of t's 
(things like setting the release version, finalizing release notes, and generating files)
and do not include new development. 
They are created from the maintenance branch at the time of the maintenance release and have 
names like hdf5_1_10_N, where N is the minor release number. Once the release is  done it is
tagged, with a slightly different format: hdf5-1_10_N. 
Release branches are deleted after the tag has been created. If we have to create a patch version
of a release (which is rare), we create a branch off of the tag.

\section sec_branchexpl_feature feature/\*
Feature branches are temporary branches used to develop new features in HDF5.
Feature branches branch off of develop and exist as long as the feature is under development. 
When the feature is complete, the branch is merged back into develop, as well as into any support
branches in which the change will be included, and then the feature branch is removed.

Ideally, all feature branches should contain a BRANCH.md file in the root directory that explains
the purpose of the branch, contact information for the person responsible, and, if possible, some
clues about the branch's life cycle (so we have an idea about when it can be deleted, merged, or
declared inactive).

Minor bug fixes and refactoring work usually takes place on personal forks, not feature branches.

\section sec_branchexpl_inactive inactive/\*
These branches are for experimental features that were developed in the past, have not been merged
to develop, and are not under active development. The exception to this is that some feature branches
are labeled inactive and preserved for a short time after merging to develop. Integration branches
are usually not kept in sync with the develop branch.

As for feature branches, inactive branches should have a BRANCH.md file as described above.

<hr>
Navigate back: \ref index "Main" / \ref TN

*/
