mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-25 04:09:44 +03:00
Scot Breitenfeld
05676d1abe
* Consolidate documentation under doc/ directory
Move user-facing guides from release_docs/ and doxygen/ into a single
doc/ root. release_docs/ now holds only release artifacts (changelogs,
history, release process, maintainer info).
- git mv release_docs/INSTALL*.md, USING_*.md, README_HPC.md,
BuildSystemNotes.md, AutotoolsToCMakeOptions.md,
HDF5_Library_2.0.0_Migration_Guide.md → doc/
- git mv doxygen/ → doc/doxygen/
- Update CMakeLists.txt: HDF5_DOXYGEN_DIR and add_subdirectory path
- Update CMakeInstallation.cmake: all install paths for moved files
- Update bin/make_vers: hardcoded doxygen/ path substitution
- Update doc/doxygen/CMakeLists.txt: EXAMPLES_DIRECTORY and comments
- Update README.md, CONTRIBUTING.md, SECURITY.md, config/README.md,
release_docs/RELEASE_PROCESS.md: links to moved files
- Update doxygen .dox files: release_docs/ URLs for moved guides
- Rewrite release_docs/README.md for narrowed scope
* Add HDF5_DOCS_DIR variable for doc/ root path
Introduce HDF5_DOCS_DIR = \${HDF5_SOURCE_DIR}/doc so that
CMakeInstallation.cmake and future callers reference the doc/
directory symbolically rather than by hardcoded path.
HDF5_DOXYGEN_DIR is now derived from HDF5_DOCS_DIR.
70 lines
3.7 KiB
Plaintext
70 lines
3.7 KiB
Plaintext
/** \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
|
|
|
|
*/
|