Update release actions to working version

pplantinga · pplantinga · commit 4853a44f65fa · 2021-06-05T18:20:04.000-04:00
diff --git a/.github/workflows/newtag.yml b/.github/workflows/newtag.yml
@@ -1,20 +1,18 @@
-name: "Draft release when pushing to main"
+name: "Draft release when pushing new tag"
 
 on:  # yamllint disable-line rule:truthy
   push:
-    branches:
-      - "main"
+    tags:
+      - "v*"
 
 jobs:
   pre-release:
     name: "Draft release"
     runs-on: "ubuntu-latest"
 
     steps:
-      - uses: "marvinpinto/action-automatic-releases@v1.1.2"
+      - uses: "marvinpinto/action-automatic-releases@v1.2.0"
         with:
           repo_token: "${{ secrets.GITHUB_TOKEN }}"
-          automatic_release_tag: "latest"
           draft: True
           prerelease: False
-          title: "Change this to vX.Y.Z"
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
@@ -18,15 +18,6 @@ jobs:
       - uses: actions/setup-python@v2
         with:
           python-version: 3.8
-      - uses: battila7/get-version-action@v2
-      - name: Update version.txt
-        run: |
-          echo ${{ steps.get_version.outputs.version-without-v }} > speechbrain/version.txt
-          git config user.name github-actions
-          git config user.email github-actions@github.com
-          git add speechbrain/version.txt
-          git commit -m 'Auto-update version.txt'
-          git push
       - name: Install pypa/build
         run: python -m pip install build --user
       - name: Build binary wheel and source tarball
diff --git a/docs/contributing.md b/docs/contributing.md
@@ -186,23 +186,24 @@ of what this would likely mean:
  * Added classes or features warrant a minor version bump. Most weekly updates should fall into this.
  * Patch version bumps should happen only for bug fixes.
 
-When releasing a new version, there are only two user-initiated action that need to occur.
-First, the `develop` branch should be merged to the `main` branch. This means that
-the `main` branch now includes the latest changes to the repository. Second,
-the `main` branch should be tagged with the new version. This is done by
-navigating to the `Releases` page, drafting a new release, and publishing it.
-
-The published release should include a summary of changes from the prior
-version. We have created a GitHub action that is run when the `develop`
-branch is merged with the `main` branch that creates a draft release
-titled "Latest". This draft release should include commits since
-the previous release, but will require some editing to summarize or
-highlight important changes.
-
+When releasing a new version, there are a few user-initiated action that need to occur.
+ 1. On the `develop` branch, update `speechbrain/version.txt` to say the new version:
+    X.Y.Z
+ 2. Merge the `develop` branch into the `main` branch:
+    git checkout main
+    git merge develop
+ 3. Push the `main` branch to github:
+    git push
+ 4. Tag the `main` branch with the new version:
+    git tag vX.Y.Z
+ 5. Push the new tag to github:
+    git push --tags
+
+This kicks off an automatic action that creates a draft release with release notes.
+Review the notes to make sure they make sense and remove commits that aren't important.
+You can then publish the release to make it public.
 Publishing a new release kicks off a series of automatic tools, listed below:
 
- * The file `version.txt` gets updated with the version (excluding "v") named
-   in the release. This update gets pushed to both `main` and `develop` branches.
  * The `main` branch is checked out and used for building a python package.
  * The built package is uploaded to PyPI and the release is published there.
  * Read the Docs uses Webhooks to get notified when a new version is published.
