No way to have an x.x.0 release using GitHubFlow

[distantcam]

Yes, this is a duplicate of #124 that was closed without being fixed, and I cannot reopen it.

There's still no easy way to have an x.x.0 release when tagging the repo. Instead you end up with a commit that's tagged wrong, and an unnecessary version file just to get an x.x.0+0 build.

Having the wrong tag also means the GitHub release is wrong too.

[distantcam]

Ok, I've created a failing test for the scenario I'm thinking of.

The question is, is it valid?

The current behaviour is to bump the tag number if there are commits. So the current test has tag 1.0.3 and 5 commits being 1.0.4+5 which is fine.

But if you have tag 1.0.3 and no commits currently the version will be 1.0.4+0 and I think it should be 1.0.3+0.

Thoughts? cc @JakeGinnivan

[JakeGinnivan]

The way I am using it is:

• Given 1.0.0 is tagged, build server is building 1.0.1
• If I want to release 2.0.0, I use nextversion.txt with 2.0.0 in it or a release-2.0.0 branch
  • This causes the build server to build 2.0.0
• When i am happy with 2.0.0 I will hit the release build it will:
  • Take the artifacts from my CI build
  • Tag the commit 2.0.0 (I then will manually create the GitHubRelease, but that can be automated with GitReleaseNotes soon)

The idea is that GitVersion is always building the next version, tags indicate a released version, not a to be released version

[JakeGinnivan]

Short answer, tags are used for marking a release, not bumping the version number :)

[JakeGinnivan]

So, back to you. Does this workflow work for you, if not, why? :)

[robdmoore]

What about repeatability?

If you need to re-run the build for that tagged commit should it have the same version number as when it was built before tagging?

[JakeGinnivan]

That is true, i was thinking about the workflow. Not sure when you would need to repeat the CI build after a deployment has happened for that version, but it is something we should support.

So basically, the rule we want is:

If the HEAD is tagged, that tag should be ignored by GitVersion.

Any problems with adding this rule @andreasohlund

[andreasohlund]

Aren't we using tags as a way to force a version? (eg when you migrate from
another repo and what that version to be X)

If yes wouldn't that rule break this?

On Wed, Jun 4, 2014 at 12:31 PM, Jake Ginnivan notifications@github.com
wrote:

That is true, i was thinking about the workflow. Not sure when you would
need to repeat the CI build after a deployment has happened for that
version, but it is something we should support.

So basically, the rule we want is:

If the HEAD is tagged, that tag should be ignored by GitVersion.

Any problems with adding this rule @andreasohlund
https://github.com/andreasohlund

—
Reply to this email directly or view it on GitHub
#186 (comment)
.

[JakeGinnivan]

@andreasohlund I think that is the problem actually.

If I tag 1.0.0, then rebuild that commit will build as 1.0.1. If we add the rule in, tagging HEAD and rebuild will cause the same version to be built as before the tag

[robdmoore]

Unless that tag is different from nextversion.txt or the minor version bump from the previous tag (if any).

Perhaps the logic should be use the version in the tag, but the number of commits before it in the metadata?

[JakeGinnivan]

@robdmoore if it is different to NextVersion.txt, that shouldn't matter. If you tag lower than nextversion.txt, then nextversion.txt would take precedence whether the tag was included or not. Where would we actually need this logic?

Second point, the tag should come from the version created by GitVersion so if we ignore the tag on HEAD then the calculated version should be the same as the tag.

[distantcam]

When i am happy with 2.0.0 I will hit the release build it will:
Take the artifacts from my CI build
Tag the commit 2.0.0 ...

Ah, so you take the artifacts, then tag the release, thus ensuring you can never build version 2.0.0 again because now it's tagged it'll build as 2.0.1. Yes using the head's tag would work because I would work the other way, tag the commit, then have the CI build the artifacts, which should use the tagged version.

[distantcam]

If there's commits after the tag, then an autobump is fine. It's just the commit that has the tag I think should honour that tag.

Another scenario for historical builds, often with packages that don't distribute their symbol files, I grab their repo, build from the right version tag, and add the pdbs in to debug. Historical repeatable builds are useful.

[robdmoore]

If you take a continuous delivery approach you don't know which build will be the release - all builds are release candidates. Hence why we build first then tag when release.

[JakeGinnivan]

Ok, i think we are all on the same page.

Can anyone come up with an example which would break the rule, if HEAD is tagged, ignore that tag

That way you can checkout tags, and it will run ignoring that tag which means the version will not be bumped.

[robdmoore]

Only when it's the first tag in the repo