Description
When reviewing PRs from the upstream repo, I saw several PRs that added extra updaters:
- feat(updater): add Gradle support conventional-changelog/standard-version#788
- adding YAML support conventional-changelog/standard-version#748
- feat: support bumping python versions conventional-changelog/standard-version#643
- feat(Java): add support for Java projects which use Maven or Gradle conventional-changelog/standard-version#591
Should this project accept them? They're all in line with this fork's north star, but there are good arguments both ways for adding new updater types (this PR in particular has good discussion)
I think the point that we don't want to maintain hundreds of different file types is strong, but also there are practically only a handful of file types for the popular ecosystems. I think it would be a substantial improvement to support the popular ones out-of-the-box, without need for plugins.
I'd like to bring in support for common languages and ecosystems. Here's a proposal for the guidelines to follow when bringing in a new updater:
We can add an updater to this project provided:
- It is for a popular ecosystem/language/framework that the average developer is at least aware of
- It does not add a requirement to have a package.json (
npx commit-and-tag-version
should work with no package.json or other additional files beyond config) - The updater can be expected to work on generally on that particular file type - I don't want to accept "here's a regex that happens to work for my project" if we can't expect it to work for all projects
- The updater does not add dependencies that might cause problems for users who aren't using that updater. There might be situations where it's appropriate to call out to tools that belong to a particular ecosystem (eg maven) - I think that's ok, as long as:
- It doesn't require those tools to be present if you're not using that updater
- When using that updater and the tool isn't present, failure is graceful
Thoughts?