git flow release start 0.0.0 with version prefix adds prefix to tag, but not branch

[AGBrown]

If I do:

mkdir test
cd test
git init
git flow init -d
git flow config set versiontagprefix v
git flow feature start test
echo test > test.txt
git add -A
git commit -a -m "test commit"
git flow feature finish --no-ff
git flow release start 0.0.0

Then the branch is created as release/0.0.0 and not release/v0.0.0:

Switched to a new branch 'release/0.0.0'

The prefix config has taken effect though as when I then do

git flow release finish

• The tag is named v0.0.0.
• The branch -> master merge message still says Merge branch 'release/0.0.0'
• The tag -> develop merge message still says Merge tag 'v0.0.0' into develop

Would it be less confusing to name the release branch in the same way as the tag? i.e. release/v0.0.0 and not release/0.0.0?

As it currently stands we aren't using git flow config set versiontagprefix v as it means people aren't sure if they should start release 1.0.0 or start release v1.0.0 (which would then end up with a tag called vv1.0.0)

[petervanderdoes]

I can see the confusing it could bring. Could you live with a configuration setting that you could set to make this happen?

Something like git flow config set useversionprefixwithbranch true

That config could be set local,global or system wide.

[AGBrown]

Could you live with a configuration setting that you could set to make this happen

I could easily live with that. My concern about suggesting we make it add the prefix to the branch version number is that it is essentially a breaking change - suddenly other people would see the behaviour change if they were using the prefix in its current form.

Would other people understand how it works? As long as we updated the documentation e.g. this that should be ok.

As git flow is about standardising workflow (individually and across a team), then it would be nice if it standardised version prefixing. Ideally I think the logic would be:

1. If no prefix is set in the configuration, then its up to the user to set the prefix when doing git flow release start <prefix><version number>
2. If a prefix is set in the configuration, then:
   • if the user forgets a prefix during git flow release start then it adds the prefix to the branch name and tag
   • if the user specifies the prefix during git flow release start, it doesn't duplicate it on the branch name and tag (like it currently does with the tag)

[AGBrown]

FWIW, I just realised that it looks like this repo could also benefit from this kind of standardisation:

1. 1.8.0
2. v1.9.0 <-- oops
3. 1.9.1

This standardisation of version number format trips me up all the time - it would be nice if it was part of the overall gitflow workflow standardisation.

[petervanderdoes]

Forgot to include this in the release

[Wirone]

IMO this is proper behavior. Tag prefix is configurable so appending it to branch's name would kill its purpose. Imagine scenario: you do git flow init with empty prefix, you create release/1.0.0 branch but then you realize you want v prefix, so you change your config - if prefix wasn't added when release is finished, you wouldn't get v1.0.0 tag from existing branch. Changing configuration would make effect only on future releases and hotfixes. I think it's wrong. Version used in branchs' names should be "bare", prefix should be applied at the moment of creating tag.

[Wirone]

BTW. inconsistency in this project's tags may be result of maintaining repo by multiple users with different configuration, single person who changes configuration or... Git Flow binaries are not used while maintaining this repo ;) And probably that's the case.

[shaunthegeek]

This usage is widely recognized, the easy way to remember:

prefix is only for git tag, not for version.

same as npm:

$ cat package.json | grep version
  "version": "1.1.0",
$ git tag
v1.0.0
v1.1.0

$ npm version minor
v1.2.0

$ cat package.json | grep version
  "version": "1.2.0",
$ git tag
v1.0.0
v1.1.0
v1.2.0