Problems with date-based versioning (e.g., 140829) when doing releases with HubFlow

[raamdev]

Let's say we start a new release for testing (git hf release start 140820). That gives us a branch called release/140820. We test that Release Candidate and commit any last-minute fixes to that release branch.

When we're done testing and ready to do a public release, let's say 9 days later on 2014-08-29, we finish the release with git hf release finish 140820. However, that causes the HubFlow tools to assume that our public release version is 140820, when in fact it's 140829 (because we're using date-based versioning instead of semantic versioning).

That assumption by the HubFlow tools leads to the following when doing git hf release finish 140820:

• A tag for 140820 is created--this is an unnecessary tag, since we really want that tag to be called 140829; the version of our public release.
• A commit message is added that says Merge tag '140820' into 000000-dev, when really that should say Merge tag '140829' into 000000-dev

---

While these issues don't cause any real problems, they do create unnecessary confusion and add stuff that makes things messy in the long-run.

When I create the Release in GitHub, I end up tagging that release with a new tag (140829) instead of being able to select an existing tag (technically, I could select the new 140820 tag, since it represents the correct point in history, but the name doesn't make sense since the release version is 140829).

A simple solution to this problem with using date-based versioning might be to allow an additional argument at the end of a git hf release finish command that specifies the name of the tag that should be created (i.e., the version of the public release):

git hf release finish 140820 140829

[jaswrks]

Ah, I see what you mean. I like the extra argument idea.