You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add instruction to verify library version compliance with sematic
versioning with link to semantic versioning wiki page.
Update H5.c and version tests for move of major and minor versions to
1st and 2nd version numbers.
Copy file name to clipboardExpand all lines: release_docs/RELEASE_PROCESS.md
+14-10Lines changed: 14 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ For more information on the HDF5 versioning and backward and forward compatibili
57
57
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.
58
58
4. Move all unresolved Milestone issues to the next release version in GitHub.
59
59
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.
60
-
6. Verify release branches for third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to [email protected].
60
+
6. Verify released versions (latest) of third-party software used: SZIP, ZLIB, and Plugins; and announce release versions to [email protected].
61
61
62
62
### 5. Update Interface Version (Release Manager | Product Manager)
63
63
1. Verify interface additions, changes, and removals, and update the shared library interface version number.
@@ -71,9 +71,11 @@ For more information on the HDF5 versioning and backward and forward compatibili
71
71
6. Confirm the necessity of and approve of any interface-breaking changes. If any changes need to be reverted, task the developer who made the change to do so as soon as possible. If a change is reverted, return to the previous step and regenerate the compatibility report after the changes is made. Otherwise, continue to the next step.
72
72
7. Update the .so version numbers in the [config/lt_vers.am][u9] file in the support branch according to [libtool's library interface version](https://www.gnu.org/software/libtool/manual/libtool.html#Versioning) scheme.
73
73
- See [Updating version info (Libtool)](https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info) for rules to help update library version numbers.
74
-
8. After the release branch has been created, run `./autogen.sh` to regenerate build system files on the release branch and commit the changes.
74
+
8. After the release branch has been created, run bin/process_source.sh to regenerate the H5E header files on the release branch, and commit the changes.
75
75
76
-
### 6. Prepare Release Branch (Release Manager)
76
+
### 6. Verify that HDF5 library version has been updated from the previous release according to [HDF5 versioning policy][u16], consistent with semantic versioning rules.
77
+
78
+
### 7. Prepare Release Branch (Release Manager)
77
79
1. Get the release branch ready for pre-release testing and packaging.
78
80
2. For all release preparation operations, the release coordinator will clone and push directly to canonical HDF5:
@@ -93,16 +95,17 @@ For more information on the HDF5 versioning and backward and forward compatibili
93
95
-`$ bin/h5vers -s X.Y.Z-{SR+1};`
94
96
-`$ git commit -m "Updated release preparation branch version number to X.Y.Z-{SR+1}"`
95
97
-`$ git push`
96
-
7.** OBSOLETE CURRENTLY **
98
+
7. Remove 'WILL_FAIL "true"' line for minor version check in test/CMakeTests.cmake (currently line 662). Minor branches are considered incompatible for develop, but not for release branches.
99
+
8.** OBSOLETE CURRENTLY **
97
100
Update default configuration mode
98
101
-`$ git checkout hdf5_X_Y_Z;`.
99
102
- Need to set option `HDF5_GENERATE_HEADERS` to `OFF`, currently in line 996 of [src/CMakeLists.txt][u11].
100
103
- (use `git status --ignored` to see the changes and `git add -f` to add all files. First delete any new files not to be committed, notably `src/H5public.h~`.)
101
104
-`$ git push with commit message listing change steps for creating release branch`
102
105
** END OBSOLETE CURRENTLY **
103
-
8. E-mail [email protected] to indicate that the code freeze on the release support branch (i.e. hdf5_X_Y) has been lifted and development on the next maintenance release can resume. The code freeze will remain in place on the release preparation branch (i.e. hdf5_X_Y_Z) indefinitely.
106
+
9. E-mail [email protected] to indicate that the code freeze on the release support branch (i.e. hdf5_X_Y) has been lifted and development on the next maintenance release can resume. The code freeze will remain in place on the release preparation branch (i.e. hdf5_X_Y_Z) indefinitely.
1. Verify that source and binary distributions of HDF5 are acceptable on all target operating environments.
107
110
2. Create a page on Confluence as a sub-page of the current release version's project collaboration page (see HDF5 Maintenance Releases) to document release testing results.
108
111
3. Document the test procedure that will be used for this release on the new sub-page.
@@ -164,7 +167,7 @@ For more information on the HDF5 versioning and backward and forward compatibili
164
167
19. Decide if another cycle of pre-release testing should occur based on the issue reports received and the actions taken during this cycle. If another round of testing is required (i.e. there were significant issues in pre-release testing which resulted in code changes), increment the subrelease version number and go back to step 7.2. If no further testing is required (i.e. no code changes were made and issues were documented as known issues, or code changes were trivial, unit tested, and exhaustive testing is unneeded), then proceed.
165
168
166
169
167
-
### 8. Finalize Release Notes (Release Manager)
170
+
### 9. Finalize Release Notes (Release Manager)
168
171
1. Perform a final review of release notes and ensure that any new changes made to the source, any new known issues discovered, and any additional tests run since the code freeze have been reflected in CHANGELOG.md and other appropriate in-source documentation files (INSTALL_*, etc.). (Refer to the sub-steps of step 3 for what to check).
169
172
2. Update the [CHANGELOG.md][u1] in the **support** branch (i.e. hdf5_X_Y) to remove entries in “Bugs fixed” and “New Features” sections and increment the version number for the following release (“Bug fixes since X.Y.Z” - occurs twice).
170
173
-`$ git checkout hdf5_X_Y`
@@ -173,7 +176,7 @@ For more information on the HDF5 versioning and backward and forward compatibili
173
176
-`$ git push`
174
177
3. Update Release Notes in **release** branch (Release Manager)
175
178
176
-
### 9. Package and Distribute Release (Release Manager)
179
+
### 10. Package and Distribute Release (Release Manager)
177
180
1. h5vers could run genparser, which can change the generated files if certain code files have been changed since the files generated by genparser were committed on the release branch. This should be checked by running `git status --ignored;`, then running genparser, then repeating `git status --ignored;`. If there are modified files from either git status command, they should be committed (or deleted if there are backup files or an autom4te.cache directory), and at least minimal testing should be done to see that the software is still good with the changes.
178
181
2. Set version for release, removing the subrelease string, initially `$ bin/h5vers -s X.Y.Z;`. Any subsequent patch releases will need the subrelease number.
179
182
3. Run `bin/release` (similar to 8.2) and commit all the changed files.
@@ -192,9 +195,9 @@ For more information on the HDF5 versioning and backward and forward compatibili
192
195
- Press "Run Workflow"
193
196
8. Release hdf5_plugins following the same steps.
194
197
195
-
### 10. Add the contents of the CHANGELOG.md file in the release code to the HISTORY-X_Y file in the **support** branch, just below the introductory lines at the top of the HISTORY file.
198
+
### 11. Add the contents of the CHANGELOG.md file in the release code to the HISTORY-X_Y file in the **support** branch, just below the introductory lines at the top of the HISTORY file.
0 commit comments