Updates branches-explained.md (#1900)

1 files changed, 15 insertions, 16 deletions

diff --git a/doc/branches-explained.md b/doc/branches-explained.md
index 22b9c8f..5b55ec7 100644
--- a/doc/branches-explained.md
+++ b/doc/branches-explained.md
@@ -8,34 +8,33 @@ We encourage code contributors to check the status of their commits. If you have
  
 ## `develop`
 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 **all** new features are integrated into this branch from respective feature branches. 
+This is also considered the integration branch, as **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.
 
 ## `Maintenance branches`
-
-Each currently supported release-line of HDF5 (e.g. 1.8.x, 1.10.x, 1.12.x) has a support branch with the name 1_8, 1_10, 1_12. 
+Each currently supported release line of HDF5 (e.g. 1.8.x, 1.10.x, 1.12.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 **maintenance** release of that particular supported release-line of HDF5. 
 **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.
 
+## `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 Autotools 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.
+
 ## `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.
 
-## `release/*`
-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, et cetera) and do not include new development. 
-They are created from the maintenance branch at the time of the maintenance release and have 
-names 1_8_N, 1_10_N, 1_12_N, where N is the minor release number. Once the release is  done it is tagged. 
-Patches can be applied to the release branch for patch releases that are treated as "scaled down" maintenance releases as defined by Release coordinator.
-
-## `1.X/master/*` where X is 8, 10 or 12
-These branches are used to tag 1.X.* maintenance releases.
+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).
 
-## `inactive/<name>/*`
-These branches are for experimental features that were developed in the past  and have not been merged to develop, and are not under active development. The features 
-can be out of sync with the develop branch.
+Minor bug fixes and refactoring work usually takes place on personal forks, not feature branches.
 
-This document was last updated on March 16, 2021
+## `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.