Automate Release-Only Changes

[osalpekar]

First Pass for automating release-only changes.

Tested this in audio to ensure it works.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/audio/3590

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 39756e1 with merge base 5cf7d2d ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[huydhn]

LGTM! Although I think this script, as it stands, doesn't need to be on a per-repo basis because replacing branch name is done everywhere. But there might be more audio-specific steps later on I assume

[osalpekar]

@huydhn Yeah I was wondering something similar. There's nothing inherently audio-specific here, and with how the nova workflows are structured, I don't think there should be anything in the future. We can add such a script in test-infra, but might need to make some assumptions about the domain library setup. On the other hand, we could just make it a GHA, but might be overkill. Decided to just have this in each repo for now, but open to consolidation ideas.

[facebook-github-bot]

@osalpekar has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@osalpekar merged this pull request in af79867.

[github-actions]

Hey @osalpekar.
You merged this PR, but labels were not properly added. Please add a primary and secondary label (See https://github.com/pytorch/audio/blob/main/.github/process_commit.py).

---

Some guidance:

Use 'module: ops' for operations under 'torchaudio/{transforms, functional}', and ML-related components under 'torchaudio/csrc' (e.g. RNN-T loss).

Things in "examples" directory:

• 'recipe' is applicable to training recipes under the 'examples' folder,
• 'tutorial' is applicable to tutorials under the “examples/tutorials” folder
• 'example' is applicable to everything else (e.g. C++ examples)
• 'module: docs' is applicable to code documentations (not to tutorials).

Regarding examples in code documentations, please also use 'module: docs'.

Please use 'other' tag only when you’re sure the changes are not much relevant to users, or when all other tags are not applicable. Try not to use it often, in order to minimize efforts required when we prepare release notes.

---

When preparing release notes, please make sure 'documentation' and 'tutorials' occur as the last sub-categories under each primary category like 'new feature', 'improvements' or 'prototype'.

Things related to build are by default excluded from the release note, except when it impacts users. For example:
* Drop support of Python 3.7.
* Add support of Python 3.X.
* Change the way a third party library is bound (so that user needs to install it separately).

[mthrok]

@osalpekar @huydhn We ususally have release-specific changes, which is removing prototypes #3592. It would be nice that it can be incorporated.

[osalpekar]

@mthrok Sure, let me look into doing that. I'm also wondering if there's something safer we could for for handling the prototypes in the release branch - we could make the prototype directory hidden (_prototypes) signaling the underlying components are not to be imported, and we could set a flag on the prototype unittests so that they are not run on the release-branch (or just have a separate CI job for them that doesn't run on the release branch). Let me know what you think!