-
Notifications
You must be signed in to change notification settings - Fork 43
[RFC] Updaters for non-node files #33
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
Comments
Thanks for pulling this together @TimothyJones - I'll make sure that the thread here (conventional-changelog#591) moves over to this discussion. |
Hi, |
If they’re both forks, you should be able to pull the master from this (probably without tags) to a branch on your repo Alternatively, depending on your fork’s state, you might be able to PR directly- although if you’ve been releasing, that might not work |
This all seems reasonable to me. I hope to get to my original Python changes soon |
@dwmkerr Any chance of moving maven support here ? |
@samarpanB and @dwmkerr I have added a pr for Maven |
When reviewing PRs from the upstream repo, I saw several PRs that added extra updaters:
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:
npx commit-and-tag-version
should work with no package.json or other additional files beyond config)Thoughts?
The text was updated successfully, but these errors were encountered: