Change release procedure to use only pull requests
_The documentation is not available anymore as the PR was closed or merged._ The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5250). All of your documentation changes will be reflected on that endpoint. The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5250). All of your documentation changes will be reflected on that endpoint. The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5250). All of your documentation changes will be reflected on that endpoint. Little recap:
- The release-conda GH action was properly triggered by push-tag event: therefore I guess this event is also created when we publish a release and create a tag within it (as it is the case in the new procedure)
  - However, the package was only uploaded to huggingface channel and not to conda-forge channel
    - [x] Why? Need to address this.
      - Reply by @lhoestq: https://github.com/huggingface/datasets/pull/5250#discussion_r1025047531
        - We only maintain the huggingface channel
        - The conda-forge channel is maintained by the community; the 2.7.0 has been finally added as well to this channel 
- The generate-documentation GH action will be triggered by the push-to-branch event if we align the name of the release branch with the expected regex `v*-release`
  - [x] The naming has been aligned in the new procedure
  - [ ] Question: why do we have different triggering events for generate-doc and release-conda? Maybe we could set the same for both: either push-tag (when publishing the release), or push-to-branch
    - I think it will be better to use the push-tag event because in the new release procedure this happens later (when we publish the release), once we have already tested that everything works using the test-PyPI; on the contrary, the push-to-branch event happens before, even before opening the release PR: we could see afterwards that there is an issue, and cancel the Pull Request, but the docs and conda-package will already be published.
- For the naming of the dev-version branch/PR, instead of having a complicated version naming, I'm proposing:
  - Using always the same branch name `dev-version`
  - Just include a step to delete this branch locally if it exists: `git branch -D dev-version`
  - The remote version will not exist because it is deleted once the PR is merged
  - This approach is approved by @lhoestq: https://github.com/huggingface/datasets/pull/5250#discussion_r1025048300 Just one question to be addressed: why do we have different triggering events for generate-doc and release-conda? Maybe we could set the same for both: either push-tag (when publishing the release), or push-to-branch

I think it will be better to use the push-tag event because in the new release procedure this happens later (when we publish the release), once we have already tested that everything works using the test-PyPI; on the contrary, the push-to-branch event happens before, even before opening the release PR: we could see afterwards that there is an issue, and cancel the Pull Request, but the docs and conda-package will already be published.

We could even use the release-published event instead: [8694901](https://github.com/huggingface/datasets/pull/5250/commits/86949013c9dc59a07b55fad5b78104b8a03f60cd)
 @lhoestq now that we have push-tag event for both build_documentation and release-conda, we have no constraint on the naming of the release branch:
- we could name it simpler: maybe as you suggested above: https://github.com/huggingface/datasets/pull/5250#discussion_r1024119018
  `release-VERSION` instead of `vVERSION-release` (we do not use the prefix "v" anywhere in our repo)
This PR changes the release procedure so that:
- it only make changes to main branch via pull requests
- it is no longer necessary to directly commit/push to main branch

Close #5251.

