From: Tom Hromatka Date: Fri, 18 Mar 2022 16:34:23 +0000 (-0600) Subject: doc: Update the github release process X-Git-Tag: v3.0~118 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ebb44706fe81b20c6eb863337ac3f81124a14ce8;p=thirdparty%2Flibcgroup.git doc: Update the github release process Signed-off-by: Tom Hromatka Reviewed-by: Kamalesh Babulal --- diff --git a/doc/internal/release-github.md b/doc/internal/release-github.md new file mode 100644 index 00000000..95a46046 --- /dev/null +++ b/doc/internal/release-github.md @@ -0,0 +1,81 @@ +The libcgroup Release Process +=============================================================================== +https://github.com/libcgroup/libcgroup + +This is the process that should be followed when creating a new libcgroup +release. + +#### 1. Verify that all issues assigned to the release milestone have been resolved + + * https://github.com/libcgroup/libcgroup/milestones + +#### 2. Verify that the Github Actions are all passing + +#### 3. Verify that the bundled test suite runs without error + + # ./bootstrap.sh + # make check + +#### 4. Verify that the packaging is correct + + # make distcheck + +#### 5. Perform any distribution test builds + + * Oracle Linux + * Fedora Rawhide + * Red Hat Enterprise Linux + * etc. + +#### 6. If any problems were found up to this point that resulted in code changes, restart the process + +#### 7. If this is a new major/minor release, create new 'release-X.Y' branch + + # git branch "release-X.Y" + +#### 8. Update the version number in configure.ac AC_INIT(...) macro + +#### 9. Tag the release in the local repository with a signed tag + + # git tag -s -m "version X.Y.Z" vX.Y.Z + +#### 10. Build final release tarball + + # make clean + # ./bootstrap.sh + # make dist-gzip + +#### 11. Verify the release tarball in a separate directory + + + # ./configure --sysconfdir=/etc --localstatedir=/var \ + --enable-opaque-hierarchy="name=systemd" --enable-python + # make check + +#### 12. Generate a checksum for the release tarball + + # sha256sum > libcgroup-X.Y.Z.tar.gz.SHA256SUM + +#### 13. GPG sign the release tarball and checksum using the maintainer's key + + # gpg --armor --detach-sign libcgroup-X.Y.Z.tar.gz + # gpg --clearsign libcgroup-X.Y.Z.tar.gz.SHA256SUM + +#### 14. Push the release tag to the main GitHub repository + + # git push vX.Y.Z + +#### 15. Create a new GitHub release using the associated tag and upload the following files + + * libcgroup-X.Y.Z.tar.gz + * libcgroup-X.Y.Z.tar.gz.asc + * libcgroup-X.Y.Z.tar.gz.SHA256SUM + * libcgroup-X.Y.Z.tar.gz.SHA256SUM.asc + +#### 16. Update the GitHub release notes for older releases which are now unsupported + +The following Markdown text is suggested at the top of the release note, see old GitHub releases for examples. + +``` +***This release is no longer supported upstream, please use a more recent release*** +``` diff --git a/doc/internal/release-github.txt b/doc/internal/release-github.txt deleted file mode 100644 index 99e19df7..00000000 --- a/doc/internal/release-github.txt +++ /dev/null @@ -1,35 +0,0 @@ -1. Update version in configure.ac - a. AC_INIT([libcgroup],[0.XX]) - b. Add an .rcY to the end, e.g. 0.XX.rcY - c. AC_SUBST(LIBRARY_VERSION_MAJOR, 0) - AC_SUBST(LIBRARY_VERSION_MINOR, XX) - AC_SUBST(LIBRARY_VERSION_RELEASE, rcY) -2. Build - a. Run ./bootstrap.sh - b. Run ./configure --enable-opaque-hierarchy="name=systemd" - c. Run make check - d. Run make dist -3. Tag the Release - a. git tag -s -a -m "v0.XX.rcY" v0.XX.rcY -4. Push to github - a. git push origin v0.XX.rcY - b. Generate a checksum for the *.tar.gz and *.tar.bz2 and ... - sha256sum > libcgroup-X.Y.Z.tar.gz.SHA256SUM - c. Sign the tar files - gpg --armor --detach-sign libcgroup-X.Y.Z.tar.gz - gpg --armor --detach-sign libcgroup-X.Y.Z.tar.bz2 - d. Sign the SHA256 files - gpg --clearsign libcgroup-X.Y.Z.tar.gz.SHA256SUM - gpg --clearsign libcgroup-X.Y.Z.tar.bz2.SHA256SUM - e. Upload the zips, checksums, and signing files to the github - release - f. Email libcg-devel about the new release w/ the changelog - git shortlog v0.XX.rc(Y-1)..v0.XX.rcY -5. Verify continuous integration passes - a. Verify TravisCI, code coverage, etc. all pass - b. If the CI checks fail, fix it, and go back to step #1 -6. Fix issues identified as critical for current rc(Y+1) - a. If any issues fixed, update the rcY number and go to step #1 - b. If no issues, go to step #7 -7. Release Notes -8. Do steps #1 through #5 (except step #1b) diff --git a/doc/internal/release.txt b/doc/internal/release.txt deleted file mode 100644 index 0b075f7b..00000000 --- a/doc/internal/release.txt +++ /dev/null @@ -1,36 +0,0 @@ -Libcgroup release procedure -=========================== -Please follow the following steps (TODO: Automate these steps) -1. Check, that every new or changed feature since last release is reflected in - README and/or man pages. -2. Bump soname of libcgroup shared objects if needed - LIBRARY_VERSION_MAJOR, - _MINOR and _RELEASE in configure.ac. -3. Prepare release candidate (X.YY-rcZ - X.YY = version, Z - prerelease -umber): - a. Update AC_INIT(X.YY.rcZ) in configure.ac. - b. Update AC_SUBST(LIBRARY_VERSION_MAJOR, X), - AC_SUBST(LIBRARY_VERSION_MINOR, YY), - AC_SUBST(LIBRARY_VERSION_RELEASE, rcZ) in configure.ac. - c. Run 'autoreconf -i' to generate the configure file again, with the - new release number. - d. Run './configure' to generate Makefile and dist/libcgroup.spec with - correct version numbers. - e. Run 'make dist' to create tarball. Fix Makefile.am files if - something goes wrong. - The tarball should contain everything needed for compilation with - simple sh, make and (optionally) rpmbuild, among others: - libcgroup-X.YY.rcZ/configure - libcgroup-X.YY.rcZ/dist/libcgroup.spec - f. Try to build rpms ('rpmbuild -ta libcgroup-X.YY.rcZ.tar.gz'), fix - errors in dist/libcgroup.spec.in file if something goes wrong. - g. Tag the pre-release in git. - h. Publish the pre-release libcgroup-X.YY.rcZ.tar.gz and announce it on - the libgroup-devel list with a changelog (git shortlog A..B is your - friend). - i. Test the pre-release and go to a) if new one is needed. - During this period, ABI of newly introduced shared symbols is *not* - stable and may change, if there is very good reason to break it. - -5. Finally release official version using the same procedure as in step 3., - only without the .rcZ version number suffix. -6. Update topic on #libcgroup IRC channel.