Open marvin-kolja opened 8 months ago
The described scenario seems to be achievable with a one-liner somewhat similar to
cider bump $versionPart && git commit . -m 'Release' && git tag $(cider version)
I'm not sure it really warrants a dedicated cider command for that.
That's a fair argument. Nevertheless, I wasn't thinking of a dedicated cider command but an opt-in feature for all the commands.
cider <command> --git
This would make it much easier to use cider while having uniform commit messages. Though this can be quickly done using a one-liner similar to the one you provided, it would also mean that every developer who uses this tool would need to come up with their own way of doing this. This tool already uses git to create the changelog; such a feature would only make it more tightly and seamlessly integrated with git.
EDIT: not to mention that a dirty staging area would require a more accurate logic to commit only the CHANGELOG.md
and pubspec.yaml
. However, I must admit this is rather a weak argument because developers should not have things in the staging area other than what they want to commit. 🙃
This tool already uses git to create the changelog; such a feature would only make it more tightly and seamlessly integrated with git.
This is not true actually. The changelog entries are added manually, you specify the change type and the text. It might be beneficial to add support for something like conventional commits though. See #7
Nevertheless, I don't quite understand the intended behavior of the --git
flag that's being suggested. Can you maybe give a few examples showing how the flag will affect the commands?
That's right, my bad!
This is not true actually. The changelog entries are added manually, you specify the change type and the text. It might be beneficial to add support for something like conventional commits though. See #7
As far as I understand, the feature idea in #7 generates the changelog from commits that follow conventional commits spec, right? Although this is a great idea it would also change this project fundamentally. If the changelog is generated from the commits there is no need for the cider log
command. Then the version bump could take all the commits made and infer the version as suggested by conventional commits.
Nevertheless, I don't quite understand the intended behavior of the
--git
flag that's being suggested. Can you maybe give a few examples showing how the flag will affect the commands?
My idea is that when the --git
flag is used the change produced by the cider command is also committed. As you already mentioned, one could use conventional commits to do so. As an example:
# Create an entry in the changelog and also commit that change with the commit message `fix: memory leak`
cider log fixed 'memory leak' --git
# Change the version, release it, and commit that change with the commit message: `v1.2.3+12`.
# Also create a tag with `v1.2.3+12`
cider bump build & cider release --git
As you can see in the second example, my idea doesn't fit this project perfectly. If the bump
(or version <version>
) command also has a commit functionality, we would be able to create a commit that changes that contains the version change and another that releases it. This, however, is something I would want in one commit. So the commands that I could imagine having this flag would be the log
and release
commands. In any case, I hope this clarifies some things.
Sure. If you feel like doing it, please give it a try. It is perhaps worth making the commit log message somewhat configurable, you may want to add a setting to the config in pubspec.yaml.
For some time now, I've been using a custom script that bumps the version in the
pubspec.yaml
file, makes a commit, and tags that commit with the version.I wanted to create my own package, but I discovered this excellent package. I don't want to redo the work here just to have that git functionality.
What do you think about this? If it's something you could see for this project, I'd develop this tailored for it and create a PR.
Let me know what you think ;)