Add major, minor, and patch labels to PRs, Issues

[kenperkins]

I think it would be nice to be able to label (and filter) PRs & issues, and to have some insight before even reviewing changes as to how they impact SemVer. There are a lot of issues and PRs that have already been submitted and there's little context to them on real or potential impact to SemVer.

I opened this in part to help to understand impact of an issue, say #66, which I assume to be major at such time as they're actually removed.

[indutny]

Good idea, +1

[brendanashworth]

This would be a good addition and make it easier for a new contributor to help out. 👍

[nelsonpecora]

👍 I think that would be helpful for maintainers, contributors, and users (who watch PRs that they want/need)

[nelsonpecora]

I am not good at interacting with robots. Glad this is getting some traction, though!

[piscisaureus]

+1 from me too.

As possible refinement, we could tag issues "bug fix", "api change" and "api addition". I think that's more clear for people who aren't thinking about semver all day long.

[kenperkins]

@piscisaureus a risk of not being explicit with semver-matching labels is someone making a mistake and not realizing that there is an implicit meaning. For example, api-change doesn't always mean breaking.

[nelsonpecora]

Yeah, I'm wary of using non-semver terminology. major means that there's an api change, and that api change is breaking. It's much more defined and explicit.

[rvagg]

We should make this happen, it's going to be really hard to track which number we should bump for each release beyond 1.0.0, it would be nice to just search through PRs for these labels.

How about: semver-major, semver-minor, semver-patch and every PR must be labelled with one of these, just like the commits have to have the additional metadata in them. The person responsible for a release can then go and hound mergers who haven't labelled PRs between releases.

[nelsonpecora]

👍 to semver-major, semver-minor, and semver-patch

[chrisdickinson]

It would be sort of neat if we could automate the addition of labels by running the tests from the tip of iojs against the PR tip -- if they pass, we can safely label it minor or patch. Otherwise, it's a major bump.

For now I don't see any problem with collaborators adding these labels where appropriate, the above suggestion is strictly a "for the future" sort of thing :)

[brendanashworth]

+1 on the general idea, but from what @chrisdickinson is saying, we'd have
to do it more reliably - a failed test could mean a major bump or just a
bad PR. However I think these tags would be really sweet for managing the
PRs.

A repository I think does a great job managing PRs and issues would be
TryGhost/Ghost, if anyone wants to take a look.

On Monday, January 12, 2015, Chris Dickinson notifications@github.com
wrote:

It would be sort of neat if we could automate the addition of labels by
running the tests from the tip of iojs against the PR tip -- if they pass,
we can safely label it minor or patch. Otherwise, it's a major bump.

For now I don't see any problem with collaborators adding these labels
where appropriate, the above suggestion is strictly a "for the future" sort
of thing :)

—
Reply to this email directly or view it on GitHub
#69 (comment).

[Fishrock123]

We now have semver-minor and semver-major.

[kenperkins]

w00t! Thanks everyone.