Document change log update better in the release instructions

Also remove the part about updating version.bkl from the pre-release
section, as this is done after the release.

As this leaves only 2 items in the numbered list of the things to do,
remove the list entirely.
This commit is contained in:
Vadim Zeitlin
2020-07-22 01:19:28 +02:00
parent d65dda59d2
commit 3c259eb56d

View File

@@ -47,44 +47,34 @@ and then run it using the new DLLs.
## Pre-Release Steps ## Pre-Release Steps
1. Perform the following steps. You can run `build/tools/pre-release.sh` to do Perform the following steps. You can run `build/tools/pre-release.sh` to do
the straightforward changes like updating the dates and checksums the straightforward changes like updating the dates and checksums
automatically, but please also review and update the contents of the README automatically, but please also review and update the contents of the README
and announcement text. and announcement text.
The Post-Release step of the previous release will have updated The Post-Release step of the previous release will have updated
the micro version of this release. If this release represents a major the micro version of this release. If this release represents a major
or minor release, these changes will have to be performed manually at or minor release, these changes will have to be performed manually at
this point. this point.
Note that the best order depends on the release being prepared: for a Note that the best order depends on the release being prepared: for a
development release, `docs/publicity/announce.txt` contains the list of the development release, `docs/publicity/announce.txt` contains the list of the
major changes since the last stable release and should be updated first, as major changes since the last stable release and should be updated first, as
this part of it can then be copied verbatim to the corresponding section of this part of it can then be copied verbatim to the corresponding section of
the README file. For the stable releases, it's probably more convenient to the README file. For the stable releases, it's probably more convenient to
update the README with the details of the changes first. update the README with the details of the changes first.
Here is the list of the files, for reference: Here is the list of the files, for reference:
* Update `docs/readme.txt`: version needs to be changed, content updated. * Update `docs/readme.txt`: version needs to be changed, content updated.
* Update `docs/release.md`: also version and reset SHA-1 sums to zeroes. * Update `docs/release.md`: also version and reset SHA-1 sums to zeroes.
* Put a date on the release line in `docs/changes.txt`. * Update `docs/changes.txt`: put the date on the release line and copy the
* Update the date in the manual (`docs/doxygen/mainpages/manual.h`). actual changes from Git notes as instructed in the file.
* Update the release announcement post in `docs/publicity/announce.txt`. * Update the date in the manual (`docs/doxygen/mainpages/manual.h`).
* Update `docs/msw/binaries.md`: at least the version, but possibly also * Update the release announcement post in `docs/publicity/announce.txt`.
the list of supported compilers. * Update `docs/msw/binaries.md`: at least the version, but possibly also
the list of supported compilers.
2. For micro releases, review the changelog to determine if any ABI changes Commit the changes and tag the release using your GPG key:
have been made. If so, or if this is a major or minor release, update
the C:R:A settings in `build/tools/version.bkl`. Then from the
`build/bakesfiles` directory run
bakefile_gen
and from the root directory run
autoconf -B build/autoconf_prepend-include
3. Commit the changes and tag the release using your GPG key:
git tag -s -m 'Tag X.Y.Z release' vX.Y.Z git tag -s -m 'Tag X.Y.Z release' vX.Y.Z
@@ -224,6 +214,10 @@ and from the root directory run
autoconf -B build/autoconf_prepend-include autoconf -B build/autoconf_prepend-include
* Restore the description of the Git notes use and create a skeleton section
for the next release in `docs/changes.txt`.
## MSW Visual Studio Official Builds ## MSW Visual Studio Official Builds
To build official x86 and x64 shared binaries the following are prerequisites: To build official x86 and x64 shared binaries the following are prerequisites: