Request to become maintainer

[maresb]

I'd like to make a build of v1.0.1 which is required for conda-forge/msal_extensions-feedstock#12 (comment).

In order to do this, the correct procedure is to make a new branch called v1.0.1. But as a non-maintainer, I don't know of any way to open a PR into a non-existing branch. Hence my request to either become a maintainer.

Alternatively, a maintainer could create a branch of that name, and I could then direct a PR to that.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

(No need to bump build number for adding a maintainer since it doesn't require a new build.)

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[maresb]

@conda-forge-admin, please rerender

[tyrius02]

Read https://conda-forge.org/#update_recipe to learn how to contribute.

1. Fork this repo
2. Create a branch in your fork for the new version (I. e. v1.0.1)
3. Update the recipe in your branch (version, sha256)
4. Commit the changes and push
5. Create a PR to merge the branch in your fork back to main in this repo

[maresb]

@tyrius02 but then after you merge, main (actually master) would be on v1.0.1, no? The git history would go v2.3.0 → v1.0.1 → v2.3.1 which would be very confusing, especially with changing the requirements back and forth. Thus the standard procedure in this case is to build old versions on a separate branch to avoid this jumping around.

[maresb]

@conda-forge-admin, please rerender

[maresb]

Giving up.