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:
@@ -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:
|
||||||
|
Reference in New Issue
Block a user