Mercurial > octave
changeset 30345:ba03a127bee1
* etc/HACKING.md: Add notes about how to merge default to stable.
author | John W. Eaton <jwe@octave.org> |
---|---|
date | Wed, 24 Nov 2021 12:19:45 -0500 |
parents | f7d1e5f1f109 |
children | 91c6288781ba |
files | etc/HACKING.md |
diffstat | 1 files changed, 74 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- a/etc/HACKING.md Wed Nov 24 09:12:01 2021 -0800 +++ b/etc/HACKING.md Wed Nov 24 12:19:45 2021 -0500 @@ -393,6 +393,80 @@ These guidelines also appear in the GNU libtool manual, see https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html. +Merging the default branch to stable before a release +----------------------------------------------------- + +To merge default to stable for a release with version == MAJOR: + +NOTE, I use two separate repos, one in `/path/to/octave-stable` that is +updated to the stable branch and one in `/path/to/octave-default` that +is updated to the default branch. + +1. Update the repo in `/path/to/octave-stable` to the most recent change + on the stable branch. Ensure that there are no pending changes (be + careful to avoid wiping out any changes you are currently working + on!): + + cd /path/to/octave-stable + hg update -C stable + +2. Merge default to stable (there should never be any conflicts here; + you are just making the stable branch be whatever is on the current + default branch): + + hg merge default + +3. Commit the change (replace VERSION with the correct version; it + should be of the form MAJOR.1.0): + + hg commit -m "maint: Merge default to stable to begin VERSION release process." + +4. Bump version numbers and release date in `configure.ac` for pre-release: + + * Set version in AC_INIT to MAJOR.0.1 + * OCTAVE_MAJOR_VERSION should already be correct. + * Set OCTAVE_MINOR_VERSION to 0. + * Set OCTAVE_PATCH_VERSION to 1. + * Set OCTAVE_RELEASE_DATE to the current date. + * Set the year in OCTAVE_COPYRIGHT to the current year. The + copyright dates in the source files should have already been + updated during the development cycle. If not, that should be done + in a separate change before the merge. + * OCTAVE_API_VERSION and shared library version numbers may be + updated in a separate changeset just prior to creating the first + test release. + + hg commit ## Use commit message similar to the one in 8f8fab4c93ae + +5. Update the repo in `/path/to/octave-default` to the most recent change + on the default branch. Ensure that there are no pending changes (be + careful to avoid wiping out any changes you are currently working + on!): + + cd /path/to/octave-default + hg update -C default + +6. Merge stable back to default (there should not be conflicts in this + merge): + + hg merge stable + hg commit -m "maint: Merge stable to default." + +7. Bump versions in `configure.ac` to begin active development of MAJOR+1: + + * Set version in AC_INIT to MAJOR+1.0.0 + * Set OCTAVE_MAJOR_VERSION to MAJOR+1 + * Set OCTAVE_MINOR_VERSION to 0 + * Set OCTAVE_PATCH_VERSION to 0 + + hg commit ## Use commit message similar to the one in 1455418a5c4c + +8. Remove functions and properties deprecated in MAJOR-1 (see ecf207896f76, + for example) + +9. Update NEWS file for next development cycle (see 0ec5eaabaf2c, for + example). + ################################################################################