From 7e5506df8d6c40a0075b72da7c16b6f9139438f1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lukas=20J=C3=BCnger?= Date: Tue, 8 Aug 2023 16:05:14 +0200 Subject: [PATCH] Update DEVELOPMENT.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Update to DEVELOPMENT.md to reflect the automatic creation of release tarballs through GitHub Actions. Signed-off-by: Lukas Jünger --- docs/DEVELOPMENT.md | 53 +++++++++++++-------------------------------- 1 file changed, 15 insertions(+), 38 deletions(-) diff --git a/docs/DEVELOPMENT.md b/docs/DEVELOPMENT.md index a5849f57..18e45289 100644 --- a/docs/DEVELOPMENT.md +++ b/docs/DEVELOPMENT.md @@ -290,7 +290,7 @@ performed by the maintainer Before creating a release snapshot, the documentation and version information in the package should be updated within the `master` branch. This includes files like - - `ChangeLog`, `RELEASENOTES`, `README`, `INSTALL` + - `RELEASENOTES`, `README`, `INSTALL`, `configure.ac`, `cci_version.h` - [Version headers](#versioning-scheme) During the release preparation phase, other functional changes @@ -308,17 +308,7 @@ performed by the maintainer git commit -m "merge master branch for x.x.x release" ``` -3. **Update the Autoconf (and other auto-generated) files** - - ``` - autoreconf -if # or config/bootstrap - git add -u # add changed files - git status # check for untracked files - git add - git commit -m "update autogenerated files for x.x.x release" - ``` - -4. **Tag the release revision** +3. **Tag the release revision** In order to keep track of the release snapshots, the revisions used for creating the release tarballs should be marked with an *annotated* @@ -326,44 +316,31 @@ performed by the maintainer ``` # git tag -a -m " " - git tag -a -m "CCI 1.0.1" 1.0.1 release + git tag -a -m "CCI 1.0.1" v1.0.1 release ``` - The tagname should contain the `` in `Major.Minor.Patch` format + The tagname should contain the `` in `vMajor.Minor.Patch` format (see [section Versioning scheme](#versioning-scheme)). Optionally, the following extensions could be added to the release name: - * `x.x.x_rc_` for release candidate (version for Accellera WG internal review) - * `x.x.x_beta_` for beta/internal versions - * `x.x.x_pub_rev_` for public review versions, and - * `x.x.x` for public release versions. + * `vx.x.x_rc_` for release candidate (version for Accellera WG internal review) + * `vx.x.x_beta_` for beta/internal versions + * `vx.x.x_pub_rev_` for public review versions, and + * `vx.x.x` for public release versions. > *NOTE:* The tag should be on the `release` branch, to enable the > automated tarball creation in the next step. -5. **Create the release tarball** +4. **Create the release tarball** - `git archive` can then be used to create the release tarball. - `git describe` can be used to obtain the correct tarball name - based on the current tag. + Pushing a tag starting with a "v" will trigger the automatic creation of a + release tarball through GitHub Actions. This tarball will be pushed to the + CCI GitHub site for download. This includes the generation of the automake + files. - ``` - PACKAGE="`basename $(git rev-parse --show-toplevel)`" # or directly 'cci' - VERSION="`git describe release`" - git archive -o ${PACKAGE}-${VERSION}.tgz \ - --prefix=${PACKAGE}-${VERSION}/ release - ``` - - > *NOTE:* Even without a tag, a quick-shot release of the - > release branch can be generated this way. - -6. **Publish the release** +5. **Publish the release** Upload the archive to the Accellera Working Group workspace for internal - review and push the changes to GitHub. - - ``` - git push accellera-official master release - ``` + review. > *NOTE:* The tag needs to be pushed explicitly.