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

Allow configurable list of conventional commits #215

Open
arielvalentin opened this issue Sep 20, 2023 · 1 comment
Open

Allow configurable list of conventional commits #215

arielvalentin opened this issue Sep 20, 2023 · 1 comment

Comments

@arielvalentin
Copy link

There are cases where we want to release a new version of gems for changes that may not be considered new features or fixes.

Some examples I can think of where the release:

  • When updating production runtime dependencies via Dependabot: chore
  • Internal refactorings, which do not change the external behavior: refactor

There is also some degree of granularity in some cases where we do not want to generate a release, e.g. chore(dev-deps), so it may be helpful to allow users to customize what attributes would trigger a release and if it would constitute a major, minor, or patch release.

match = /^(fix|feat|docs)(?:\([^()]+\))?(!?):\s+(.*)$/.match(title)

@dazuma
Copy link
Owner

dazuma commented Sep 23, 2023

We can certainly do this. However, I think this should be combined with being more descriptive in the conventional commit tags we use. For example, if we want production runtime updates to be significant, they should probably be something like deps: instead of chore:, and then we can map those to, say, patch releases. (And dev deps could either remain chore: or be something like devdeps:.) I wonder if we can configure dependabot to give us better tags.

I'll start with supporting a configurable mapping between conventional commit tags and semver types, and see how far we can get with that.

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

No branches or pull requests

2 participants