Offer alternative to use version labels instead of milestones

[davidzwa]

Detailed Description

I was just thinking what could help to organize issues more flexibly and then it struck me that version labels could help.
F.e. an issue that is labeled 1.2.3 or 1.2.0-alpha would be picked up for that release, but not an issue labeled 1.2.4.

This workflow is (subjectively):

• faster
• easier to manage (labels can be quickly switched)
• easier to learn
• easier to include/exclude issues manually
• a kickstart towards relaxing the single-label requirement (Relax restriction of one label per issue #90)

Context

I'm constantly forgetting to create milestones as this is not part of my workflow. In my honest opinion I think milestones are not always suitable, especially if the projects feature is used on Github or an external issue tracker (right now it seems married to certain platforms only, f.e. Github).

Possible Implementation

With a yaml toggle, allow the developer to change strategy to version labels instead of milestones.

Your Environment

• Version Used: 0.13.x
• Edition Used (.NET Core, .NET Framework): .NET Core Github
• Operating System and version (Windows 10, Ubuntu 18.04): Ubuntu 22.04 LTS

Would love to hear your feedback! 👍🏼

[gep13]

@davidzwa thank you for the suggestion.

I have to admit, I am not sold on the idea, but I am open to have my mind changed about it. For your first two advantages, I am not sure if I agree, I would suggest that it is as easy to switch a label as it is a milestone, but that could be simply because I am used to the workflow here.

Regarding the use of Projects, I agree that this is an area where not using a milestone would make sense, and I do think that Projects and Milestones are not used together, at least from my experience.

If we were to go down this route, we would need to spend a little bit of time brainstorming the idea, and decide how we wanted to move forward with it.

[davidzwa]

@davidzwa thank you for the suggestion.

I have to admit, I am not sold on the idea, but I am open to have my mind changed about it. For your first two advantages, I am not sure if I agree, I would suggest that it is as easy to switch a label as it is a milestone, but that could be simply because I am used to the workflow here.

Regarding the use of Projects, I agree that this is an area where not using a milestone would make sense, and I do think that Projects and Milestones are not used together, at least from my experience.

If we were to go down this route, we would need to spend a little bit of time brainstorming the idea, and decide how we wanted to move forward with it.

I dont mind brainstorming! I completely understand that GRM needs to be opinionated to be effective and as bug-free as possible.

Shall we start with brainstorming #90? That is a potentially complex mechanism that could lead to bugs, or needs thorough testing once complete.

Once we can tolerate multiple labels, we can ignore unknown labels - like the release labels suggested in this issue.