Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(package): update env-ci to version 2.0.0
- Loading branch information
1 parent
6e15c18
commit b9bd650
b9bd650There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not a
chore:commit? Always surprised by getting countless emails for new bug fix releases that do nothing but update a dependency. The CHANGELOG for env-ci mentions the only change is requiring Node 6, so this obviously didn't fix anything?b9bd650There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to deduplicate packages in your dependency tree
b9bd650There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the benefit, but I don't believe it should be considered a "bug fix". There was nothing broken. semantic-release releases often enough that this could be in the next release.
b9bd650There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I agree, but for sake of simplicity using
fix:here is the right thing todofix:is the default coming from Greenkeeper, so we just hit the merge button. It’s not worth complicated the process here, I’m sorry. I feel like the problem is too many notifications that you are receiving. Maybe try to improve how you handle them?b9bd650There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then maybe not use Greenkeeper, or ask them to change it? Renovate, dependencies.io etc all have options to configure the message prefix. And if you squash+merge you can also edit the message (if it was a consumer-breaking change or a feature for the consumer you would have to do that anyway). I personally do that for all my OS projects.
Not sure what you are suggesting what I should do, ignore notifications/PRs for new releases? How would I know which ones to ignore and which ones not because they contain actual bugfixes? I think it is more reasonable to ask that a package does not spam noop releases than asking all the consumers to ignore them...
I really love semantic-release and appreciate all the work you guys do but a big concern with semantic-release in general is "release spam" and when some of the releases don't even have any functional change I have a hard time defending it 😔
b9bd650There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i honestly don't understand the concern here. the primary purpose of semantic-release is to automate releases to the point where potential improvements don't sit on master unreleased. that translates to lots of releases.
greenkeeper differentiates between
dependenciesanddevDependenciesand only marks updates todependenciesasfix, sodevDependenciesdon't result in "spam" to consumers. greenkeeper is sending the PRs fully automated, so they aren't able to decide if the change has user facing impact or not. as much work as the maintainers here put into making this such a great tool, i don't see value to them spending extra effort beyond what greenkeeper has done automatically.using semantic-release means that we've already trained ourselves to be prepared for lots of releases, so one that doesn't really impact your use is still cheap to consume.