Update DEVELOPMENT.md

Update to DEVELOPMENT.md to reflect the automatic creation of release tarballs through GitHub Actions. Signed-off-by: Lukas Jünger <[email protected]>
accellera-official · Aug 9, 2023 · 7e5506d · 7e5506d
1 parent e35a617
commit 7e5506d
Showing 1 changed file with 15 additions and 38 deletions.
diff --git 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,62 +308,39 @@ 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 <new files to distribute>
-   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*
    and optionally signed Git tag.
 
    ```
    # git tag -a -m "<package> <version>" <version> <refspec>
-   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 `<version>` in `Major.Minor.Patch` format
+   The tagname should contain the `<version>` 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_<isodate>` for release candidate (version for Accellera WG internal review)
-   * `x.x.x_beta_<isodate>` for beta/internal versions
-   * `x.x.x_pub_rev_<isodate>` for public review versions, and
-   * `x.x.x` for public release versions.
+   * `vx.x.x_rc_<isodate>` for release candidate (version for Accellera WG internal review)
+   * `vx.x.x_beta_<isodate>` for beta/internal versions
+   * `vx.x.x_pub_rev_<isodate>` 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 <version>
-   ```
+   review.
 
    > *NOTE:* The tag needs to be pushed explicitly.