-
Notifications
You must be signed in to change notification settings - Fork 14
Allow users to config commit-analyzer #3
Comments
semantic-release doesn't push perf improvements as releases See semantic-release/commit-analyzer#3
Hey @kentcdodds, actually I wanted to make this part of the next breaking release ;) There are some more changes planned for how the commit plugin works (See here) and the underlying module changed/improved so it'll probably still take some time, but it will land eventually. Best, |
@boennemann The next release looks cool; however, how does one achieve this now (besides writing a new analyzer)? If a new analyzer is the answer, @kentcdodds, let's collab on it as I really want all changes that match one of the approved types to generate a release. Most of which would be patch releases. |
I wish I had more time to devote to this, but I don't right now. If I get some time, I'd happily collaborate if @boennemann hasn't gotten to it yet. |
@wilmoore @kentcdodds The fastest way would be to just change If you send me PR I'll release that as a "next" version of this module and you can just overwrite the default analyzer with this one, until we get to ship it as a default. Does that sound good? |
Sounds good to me. I'll leave @wilmoore to do the PR if he likes. I don't need this immediately. |
I'd actually like to see all of the following trigger a patch release:
If agreed, I'm happy to do the PR. |
I disagree with:
The others I'm good with. But I expect some might not like |
Here is the PR: semantic-release/commit-analyzer#4 Perhaps we can iterate on a configuration design going forward; however, I took a pragmatic approach and made the list above resolve to patch releases. |
@wilmoore @kentcdodds Sorry I didn't see the forest for the trees here. The plugin already supports being passed pluginConfig. How about making the respective types configurable and using the current behavior as a default? |
How would one utilize |
In the "release": {
"anaylzeCommits": {
"minor": ["feat"],
"patch": ["fix", "perf"]
}
} Something likes this could work? :) |
That would be perfect 👍 |
👍 Agreed |
I think this would solve most issues and be very desirable: semantic-release/commit-analyzer#12 I sent a PR for it: semantic-release/commit-analyzer#13 Then of course the rest of this thread holds true, and the user could always override the default behaviour configuring the plugin as suggested here: semantic-release/commit-analyzer#3 (comment) Thoughts? |
@kentcdodds btw can we change this thread's title from "Add |
perf
to commits warrenting a release
Done |
HI I have this issue semantic-release/semantic-release#261 and is there any way to make perf(*) commits bump minor version? if it's not, what do you guys do in that case? As it looks like there is no way currently. it would be nice to at least merge #4. |
@pensierinmusica how is that related to my issue? |
@safareli sorry I got confused with another thread ;) The problem here though to me seems that the last comment from @boennemann in this thread is on Oct 2015. More than 6 months have gone by... I would still like to have an answer to this: semantic-release/commit-analyzer#3 (comment) |
this is how i solved my issue |
created an npm module that allows you to set your own level ( |
If I improve performance, and that's all I do, I still want a release. Is there any problem with this?
The text was updated successfully, but these errors were encountered: