From a19ecacc26a7fbe84a325ceac3adca3cec32e627 Mon Sep 17 00:00:00 2001
From: Larry Knox <lrknox@hdfgroup.org>
Date: Thu, 12 Sep 2024 15:07:21 -0500
Subject: [PATCH 1/3] Draw attention to 3rd step in process to update so
 numbers for a release.

---
 config/lt_vers.am               | 9 +++++----
 release_docs/RELEASE_PROCESS.md | 9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/config/lt_vers.am b/config/lt_vers.am
index fade5bf1594..7ef44760918 100644
--- a/config/lt_vers.am
+++ b/config/lt_vers.am
@@ -19,17 +19,18 @@ LT_VERS_INTERFACE = 1000
 LT_VERS_AGE = 0
 LT_VERS_REVISION = 0
 
-## If the API changes *at all*, increment LT_VERS_INTERFACE and
+## 1. If the API changes *at all*, increment LT_VERS_INTERFACE and
 ## reset LT_VERS_REVISION to 0.
 ##
-## If the API changes but no function signatures are removed or
+## 2. If the API changes but no function signatures are removed or
 ## changed, also increment LT_VERS_AGE.
-## If any functions are removed from the API, or their signatures
+##
+## 3. If any functions are removed from the API, or their signatures
 ## are changed reset LT_VERS_AGE to 0 to indicate that previous
 ## versions of the API are not necessarily compatible with this
 ## version.
 ##
-## If the source changes but there are no API changes, increment
+## 4. If the source changes but there are no API changes, increment
 ## LT_VERS_REVISION.  This will happen automatically when
 ## bin/h5vers is run, but doing it manually shouldn't hurt
 ## anything.
diff --git a/release_docs/RELEASE_PROCESS.md b/release_docs/RELEASE_PROCESS.md
index b3d6f651bc8..b86e4ad188b 100644
--- a/release_docs/RELEASE_PROCESS.md
+++ b/release_docs/RELEASE_PROCESS.md
@@ -54,10 +54,11 @@ For more information on the HDF5 versioning and backward and forward compatibili
 ### 4. Freeze Code (Release Manager | Test Automation Team)
 1. Transition from performing maintenance on software to preparing for its delivery.
 2. A few days before the code freeze, announce (via a product's developer mailing list and during team meetings) the pending freeze of the code for the release. On the day of the code freeze, send a "no more commits" message for the software being released and any third party software we develop that it depends on, as well as a "no more upgrades" message for other third party software the release depends on.
-        - Recently we haven’t announced a code freeze since it doesn’t take long to create the release branch and the support branch doesn’t need to remain frozen once the release branch is created. There are a few things that can be done on the support branch before the release branch is created, in particular updating the .so numbers. 
-3. Move all unresolved Milestone issues to the next release version in GitHub.
-4. Verify that frozen code branch satisfies all existing regression test cases, and give the 'OK' to the release coordinator once all daily test configurations are passing as expected after the date of the code freeze. If there are failing tests after the code freeze date, coordinate with maintainers responsible for the failures to ensure that either the changes causing the failures are corrected or reverted. 
-5. Verify release branches for third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to hdf5lib@lists.hdfgroup.org.
+        - Recently we haven’t announced a code freeze since it doesn’t take long to create the release branch and the support branch doesn’t need to remain frozen once the release branch is created. There are a few things that can be done on the support branch before the release branch is created, in particular updating the .so numbers.  
+3. Be sure to complete all four steps for each deployed lib file in the process described in config/lt_vers.am and check that the .so numbers for lib files in binaries correctly indicate compatibility status with the previous release.  
+4. Move all unresolved Milestone issues to the next release version in GitHub.
+5. Verify that frozen code branch satisfies all existing regression test cases, and give the 'OK' to the release coordinator once all daily test configurations are passing as expected after the date of the code freeze. If there are failing tests after the code freeze date, coordinate with maintainers responsible for the failures to ensure that either the changes causing the failures are corrected or reverted. 
+6. Verify release branches for third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to hdf5lib@lists.hdfgroup.org.
 
 ### 5. Update Interface Version (Release Manager | Product Manager)
 1. Verify interface additions, changes, and removals, and update the shared library interface version number.

From bc994b131966deec1710af8deae64b7e26ab9f8f Mon Sep 17 00:00:00 2001
From: Larry Knox <lrknox@hdfgroup.org>
Date: Thu, 12 Sep 2024 15:18:43 -0500
Subject: [PATCH 2/3] Minor text expansion.

---
 release_docs/RELEASE_PROCESS.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/release_docs/RELEASE_PROCESS.md b/release_docs/RELEASE_PROCESS.md
index b86e4ad188b..9fcb479e98f 100644
--- a/release_docs/RELEASE_PROCESS.md
+++ b/release_docs/RELEASE_PROCESS.md
@@ -55,7 +55,7 @@ For more information on the HDF5 versioning and backward and forward compatibili
 1. Transition from performing maintenance on software to preparing for its delivery.
 2. A few days before the code freeze, announce (via a product's developer mailing list and during team meetings) the pending freeze of the code for the release. On the day of the code freeze, send a "no more commits" message for the software being released and any third party software we develop that it depends on, as well as a "no more upgrades" message for other third party software the release depends on.
         - Recently we haven’t announced a code freeze since it doesn’t take long to create the release branch and the support branch doesn’t need to remain frozen once the release branch is created. There are a few things that can be done on the support branch before the release branch is created, in particular updating the .so numbers.  
-3. Be sure to complete all four steps for each deployed lib file in the process described in config/lt_vers.am and check that the .so numbers for lib files in binaries correctly indicate compatibility status with the previous release.  
+3. Be sure to complete all four steps to update so numbers for each deployed lib file in the process described in config/lt_vers.am and check that the .so numbers for lib files in binaries correctly indicate compatibility status with the previous release.  
 4. Move all unresolved Milestone issues to the next release version in GitHub.
 5. Verify that frozen code branch satisfies all existing regression test cases, and give the 'OK' to the release coordinator once all daily test configurations are passing as expected after the date of the code freeze. If there are failing tests after the code freeze date, coordinate with maintainers responsible for the failures to ensure that either the changes causing the failures are corrected or reverted. 
 6. Verify release branches for third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to hdf5lib@lists.hdfgroup.org.

From 51e7f2055af633c52bc64ee1ed80cb509d288a4b Mon Sep 17 00:00:00 2001
From: Larry Knox <lrknox@hdfgroup.org>
Date: Fri, 13 Sep 2024 10:52:56 -0500
Subject: [PATCH 3/3] Update release_docs/RELEASE_PROCESS.md

---
 release_docs/RELEASE_PROCESS.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/release_docs/RELEASE_PROCESS.md b/release_docs/RELEASE_PROCESS.md
index 9fcb479e98f..e4d6139fefc 100644
--- a/release_docs/RELEASE_PROCESS.md
+++ b/release_docs/RELEASE_PROCESS.md
@@ -58,7 +58,7 @@ For more information on the HDF5 versioning and backward and forward compatibili
 3. Be sure to complete all four steps to update so numbers for each deployed lib file in the process described in config/lt_vers.am and check that the .so numbers for lib files in binaries correctly indicate compatibility status with the previous release.  
 4. Move all unresolved Milestone issues to the next release version in GitHub.
 5. Verify that frozen code branch satisfies all existing regression test cases, and give the 'OK' to the release coordinator once all daily test configurations are passing as expected after the date of the code freeze. If there are failing tests after the code freeze date, coordinate with maintainers responsible for the failures to ensure that either the changes causing the failures are corrected or reverted. 
-6. Verify release branches for third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to hdf5lib@lists.hdfgroup.org.
+6. Verify release branches for third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to hdf5lib@hdfgroup.org.
 
 ### 5. Update Interface Version (Release Manager | Product Manager)
 1. Verify interface additions, changes, and removals, and update the shared library interface version number.