Propose next version number

[shaedrich]

When running git flow release start you often find yourself pausing for a moment and asking yourself, what exactly you've changed. Does your change qualifiy as a patch or is it already a minor version jump? When using git trailers like proposed by Conventional Commits, one could guess the version number according to gitflow. So the command would be something like this:

git flow release start propose
git flow release start guess
git flow release start auto-determine

[ChrisJStone]

When running git flow release start you often find yourself pausing for a moment and asking yourself, what exactly you've changed. Does your change qualifiy as a patch or is it already a minor version jump?

This is actually covered in the FAQ of the conventional commits spec, in short any new features would be considered a MINOR release, fix type commits would be considered a PATCH release and anything that would qualify as a breaking change would be a MAJOR release. Paragraphs 6,7 and 8 of the semver spec
provide additional context on how to increment the version.

That being said, git-flow-cjs does have a couple of filter-hooks that can be used to help with automatically setting the version depending on the type of branch. Specifically filter-flow-release-start-version and filter-flow-hotfix-start-version. There are a number of git-flow-hooks repos on github that have already implemented the scripts to auto set the version. Some even handle changelog generation as well. At the latest version 3 will have working hook scripts included for setting the minor and patch level version number based on branch and existing tags.

[shaedrich]

@ChrisJStone Yeah, I know. It's not about knowing in general. It's about not knowing every commit you made that will go into this release. So this command would check the commits for you and determine what kind of version it will be based on the conditions, you described. Yep, I'm after that auto-setting feature.

Ah, thanks. I come from gitflow-avh where, to my knowledge, this wasn't possible. I'll have a look into these filters and hooks you recommended 👍

[ChrisJStone]

It's about not knowing every commit you made that will go into this release. So this command would check the commits for you and determine what kind of version it will be based on the conditions, you described.

Okay, I see what your getting at here. I do apologize if my previous reply seemed to be a little condescending that was not my intention. I think IMO this comes down in part to committing to many changes of different types at one time. I know I'm personally guilty of this. I don't know how many times I've made a bunch of changes to a file or multiple files then struggle how to write the commit message and as a result not knowing how to increment the version so I usually end up calling it a minor release since you can include patch level changes in a minor release.

I have recently learned about the -p flag for add which allows you to stage individual changes at the patch level and leave other changes to be committed at a latter time.

I think using add -p in combination with cz-cli "I also just found cz-git which uses OpenAI to generate commit message or a similar tool. In combination with a tool such as recommended-bump or maybe release-please would go a long way in providing the functionality you've suggested.

I also feel the following discussion is related to this as well Should support for github workflows be added to git-flow

[shaedrich]

I do apologize if my previous reply seemed to be a little condescending that was not my intention.

Yeah, same here. I'm guilty of this as well, I think. However, when reading your second paragraph, it became quite clear, that it wasn't condescending.

Two many changes per release is bad practise—agreed. That's why there are micro commits. I concur, git add -p is such a lifesaver! I knew this practise from my IDE's GUI but thought, it was added on top of git instead of being part of git itself. I use it every now and then now, and it has become one of my favorite commands if one can say so.

However, unlike with commits, you can't always decide the size of a release when you're working on a project with others. So for some reason, releases might be a bit bloated.

Wow, cz-cli looks very impressive!

I also feel the following discussion is related to this as well #44

Supporting GitHub workflows would, in my opinion, only make sense if it isn't limited to GitHub per se. Since gitflow is a universal tool and not propritary, it should work with GitLab, Bitbucket and the like as well. So there's either a common denominator (preferred) or there has to be functionality for each platform added (might not be advisable since it could be a bottomless pit).

[ChrisJStone]

git flow release start propose
git flow release start guess
git flow release start auto-determine

I just discovered [GitVersion](https://gitversion.net/} the README states it looks at the git commit history and works out the semantic version of the commit being built. It also supports git flow, I havent had a chance to fully look into yet. However I think it will negate the need for the above commands. I've also update #44 to be a general proposal instead of a specific workflow.

[shaedrich]

Sounds great! I'll also try to have a look into it 👍🏻