'git push --follow-tags' does a little too much, any spurious tag
object that the releaser have in their local repository will come
along, even though they have nothing to do with the commits being
pushed.
Therefore, we modify the instructions to show a separate and explicit
push of the release tag.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13159)
It now creates all the necessary feature branches for github in your
repository, making the cloned sub-directory unnecessary for post-release
purposes.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12614)
Doing this is kind of contrary to how we normally do things, as this
constitutes a kind of pre-approval. However, without this, the normal
review process will modify the reviewed commits, and render the
annotated release tag invalid, which forces the person doing the
release to re-tag manually.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11630)
The old release script that exists in another repository has aged, and
risks becoming messy beyond maintainability if it's made to deal with
multiple OpenSSL version schemes.
A solution, which has been seen in other projects, is to have the
release script as part of the versioned source tree, and ensure it's
adapted for the ongoing version scheme in that source tree.
This introduces dev/, a directory of OpenSSL developer "stuff". We
may expand it with other practical scripts to easy development setup
and other similar things that developers may need. For now, it's the
release script dev/release.sh, with auxilliary files in dev/release-aux/.
The script is self describing, the manual is available by running the
command `./dev/release.sh --manual`.
The dev/ directory shall never appear in a source distribution.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11516)
