* README-release: New file. --- README-release | 29 +++++++++++++++++++++++++++++ 1 files changed, 29 insertions(+), 0 deletions(-) create mode 100644 README-release
diff --git a/README-release b/README-release new file mode 100644 index 0000000..3aaa1b4 --- /dev/null +++ b/README-release @@ -0,0 +1,29 @@ +Here is most of the steps we (maintainers) follow when making a release. + +1. Execute build-aux/parted-release. `parted-release --help` contains + additional information. + +2. Test the tarball. Copy it to a few odd-ball systems and ensure that it + builds and passes all tests. + +3. Write the release announcement that will be posted to the mailing lists. + You can look at similar messages in + http://lists.gnu.org/mailman/listinfo/info-gnu for guidance. + You can also look at the announce_template file created by the release script. + +4. Run the gnupload command that was suggested by the release script. You can + find this at the end of release.log. + +5. Wait a few minutes (maybe up to 30?) and then use the release URLs to + download all tarball/signature pairs and use gpg --verify to ensure that + they're all valid. You will also need to verify these URLs in the + announcement mail. + +6. Push the new tag with the following command: + git push origin tag v$v + +7. Send the gpg-signed announcement mail, e.g., + To: [email protected], [email protected] + Cc: [email protected], [email protected] + Subject: parted-$v released [stable] + -- 1.6.0.6 _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
