Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow to specify labels to "github.changelog.feature" #96

Closed
wants to merge 1 commit into from

Conversation

micooz
Copy link
Contributor

@micooz micooz commented May 24, 2017

No description provided.

@nemobot nemobot added the WIP label May 24, 2017
@FrancescoCioria
Copy link
Contributor

Hi @micooz, thank you for this PR! I'll review it shortly

Copy link
Contributor

@FrancescoCioria FrancescoCioria left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With these changes, you're not simply allowing to use a specific label to identify a feature but you're actually requiring it.

Even more, if there is at least one issue without any label the whole script will fail.

What is exactly your pain point?
How would you like issues without any label to appear on the changelog?

@micooz
Copy link
Contributor Author

micooz commented May 24, 2017

Hi, @FrancescoCioria, I think it's weird to treat non-(bug/breaking) as feature if no ignoredLabels provided.

bug, breaking and feature should be at the same level, so labels is required for feature just as bug and breaking do.

Pass labels to feature explicitly makes it clear to know what kind of issues should be grouped.

Issues without any labels probably are not considered to be a change so it shouldn't appear in the changelog.

@FrancescoCioria
Copy link
Contributor

Mmm, I don't agree for this simple reason: A chengelog with useless information is better than a changelog without important information.

With your implementation, If you forget to add the label "feature" your users will not see that feature while, with current implementation, if you forget to add a label to ignore an issue, your users will see a not-important issue.

The second option sounds much safer to me as a default.

Nevertheless I agree with you that devs should be able to overwrite this defaults and choose how issues without known labels should be treated.

Instead of changing the logic I would improve the config with a two new options:
one to decide the label for feature issues (def "feature"?) and the other option as an enum to decide how to treat issues with no known labels and treat it by default as "feature-issues".

With this implementation, in your case, you could pass to this hypothetical option "ignore" and so you'd be forced to pass the label "feature" (or whatever you choose in the config) to set an issue as a feature.

Would this be ok with you? :)

@micooz
Copy link
Contributor Author

micooz commented May 31, 2017

Sorry for my late, it seems a good idea. Looking forward to your enhancement!

@FrancescoCioria
Copy link
Contributor

@micooz I opened #100
I hope i can work on it soon :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants