Add workflow to create version labels on new releases

[lucasbento]

Summary

This PR adds the following GitHub actions:

• https://github.com/lucasbento/core-workflow-create-version-label - Create version labels (such as Version: 0.65.1) whenever there's a new release;
• https://github.com/lucasbento/core-workflow-apply-version-label - Apply a version label to opened/edited issues based on the version mentioned on the issue body.

Changelog

N/A.

Few things to keep in mind

• A label named "Version: unspecified" must be created;
• The GitHub action to create labels will only run when there's a new release or if one is edited, it will then create all the other labels bases on the previous releases until it encounters one that already exists.

---

Example of issue with version label: lucasbento/test-issue-forms#4

[pull-bot]

	Messages
📖	📋 Verify Changelog Format - A changelog entry has the following format: [CATEGORY] [TYPE] - Message. Details CATEGORY may be: General iOS Android JavaScript Internal (for changes that do not need to be called out in the release notes) TYPE may be: Added, for new features. Changed, for changes in existing functionality. Deprecated, for soon-to-be removed features. Removed, for now removed features. Fixed, for any bug fixes. Security, in case of vulnerabilities. MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.
📖	📋 Missing Test Plan - Can you add a Test Plan? To do so, add a "## Test Plan" section to your PR description. A Test Plan lets us know how these changes were tested.

Generated by 🚫 dangerJS against f9d167e

[pull-bot]

PR build artifact for 4f25959 is ready.
To use, download tarball from "Artifacts" tab in this CircleCI job then run yarn add <path to tarball> in your React Native project.

[cortinico]

* Create version labels (such as `Version: 0.65.1`) whenever there's a new release;

Was this approach discussed somewhere? Is there a reason why we're not using Milestone instead?

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,289,510	-1,032
android	hermes	armeabi-v7a	7,853,642	-932
android	hermes	x86	8,656,565	-1,058
android	hermes	x86_64	8,615,703	-1,049
android	jsc	arm64-v8a	9,791,232	-547
android	jsc	armeabi-v7a	8,752,162	-447
android	jsc	x86	9,740,152	-559
android	jsc	x86_64	10,340,998	-569

Base commit: 6790cf1
Branch: main

[lucasbento]

Was this approach discussed somewhere? Is there a reason why we're not using Milestone instead?

It was discussed on Discord, not sure about the milestones, perhaps @lunaleaps can chime in.

[pull-bot]

PR build artifact for f9d167e is ready.
To use, download tarball from "Artifacts" tab in this CircleCI job then run yarn add <path to tarball> in your React Native project.

[lunaleaps]

Hey @cortinico, yea as @lucasbento mentioned we've been talking about deprecating upgrade-support repo to have upgrade issues reported in this repo. We want to get signal of how many issues come up when people attempt to migrate to a specific version so we can feedback on how stable our releases are -- hence using labels.

From looking at milestones, I think the use case seems to be more about tracking a specific goal -- or am I misunderstanding?

[lunaleaps]

Oh yes! Great idea

[facebook-github-bot]

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

[cortinico]

Sorry I didn't wanted to sidetrack your original work. If you already spent time discussing on this, feel free to merge it as it is.

I anyway think that using milestones for this kind of work would be better for a variety of reasons:

From looking at milestones, I think the use case seems to be more about tracking a specific goal -- or am I misunderstanding?

That's true, if used on PRs. Milestone are basically "version" information that can be attached to an issue or a PR.

Say for a potential milestone "0.67.0", I would use it in a following way:

• Mark a PR with that milestone if I intend to ship that code in version "0.67.0"
• Mark a issue/feature-request with that milestone if I intend to release that feature in version "0.67.0"
• Mark a bug with that milestone, if want to specify which version introduced that bug, say "0.67.0" <- That's apparently the use case we're looking for.

The problem that I see with the current approach are the following:

• The label space will be polluted with a lot of version-specific labels. We already have 188 labels, and we will end up having way more. Milestones instead can be "closed" and they won't show up in the dropdown selector anymore (but they will still be searchable).
• We're adding two new Github Actions from a 3rd party users (nothing against you @lucasbento), but this is a part of infra that we will have to maintain in the long run.
• I believe this could have been implemented as part of the react-native-bot: https://github.com/hramos/react-native-bot/.

[lunaleaps]

@cortinico Thanks for sharing your thoughts! For sure good points and good things to address. At this stage I think labels work well because internal tooling already scrapes this information and I'm not sure if milestones are. I think this is something we can ask about but I already have some tables built out for getting this information.

Is there a cause for concern if there are too many labels? Not exactly sure the cost except for maybe some upper bound of labels that Github allows? Tried searching around but can't find.

Re: react-native-bot, would that not be an actor that would still need to perform these actions? We can look into conforming the tools -- first want to focus on use-case

[cortinico]

Is there a cause for concern if there are too many labels? Not exactly sure the cost except for maybe some upper bound of labels that Github allows? Tried searching around but can't find.

I don't think we're going to hit the limit (if any) :) Is more like a practicality 👍

but I already have some tables built out for getting this information.

Yup I didn't want to slow down 👍 Feel free to merge it

[facebook-github-bot]

@lunaleaps merged this pull request in 60352a9.