No way to have an x.x.0 release using GitHubFlow #186
Comments
|
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 But if you have tag Thoughts? cc @JakeGinnivan |
|
The way I am using it is:
The idea is that GitVersion is always building the next version, tags indicate a released version, not a to be released version |
|
Short answer, tags are used for marking a release, not bumping the version number :) |
|
So, back to you. Does this workflow work for you, if not, why? :) |
|
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? |
|
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 |
|
Aren't we using tags as a way to force a version? (eg when you migrate from If yes wouldn't that rule break this? On Wed, Jun 4, 2014 at 12:31 PM, Jake Ginnivan [email protected]
|
|
@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 |
|
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? |
|
@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. |
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. |
|
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. |
|
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. |
|
Ok, i think we are all on the same page. Can anyone come up with an example which would break the rule, That way you can checkout tags, and it will run ignoring that tag which means the version will not be bumped. |
|
Only when it's the first tag in the repo |
|
@robdmoore can you elaborate? |
|
I think that ignoring the tag on HEAD is better than it trumping all other rules (it is also easier to implement). Actually, I now see what @andreasohlund meant. If a repo converts to GitVersion at some point, building an old tag before it was using it will end up generating a different version to the tag. Taking that into account, I think maybe @distantcam is right. If we are building a tag, use the tag. |
|
Yep that's the scenario I meant. See my AzureWebFarm project as an example. I tagged a commit a fair way down with 0.9.27 or something like that and it was the first tag in the repo. |
|
I've made some failing tests with the expected versions. Please check those tests and see if you agree with them or not. |
|
Oh, but we can't ever do historical builds with GitVersion because of #179 and not being able to build from a detached head. I'll go fix that too. |
|
Thanks Cam, the tests look good to me apart from the first. Not sure of the use case of that scenario (I have learnt stuff so far in this thread, so happy to learn more :P) In general I say go ahead, would just like your response on that comment I put on your tests if possible |
|
I'm in favour of just using the tag if there is one. I'd like to specify the version with a tag. Let's me commit on master without the need for a release branch or version.txt. And if I need to bump the version, I can simply add a tag. Not sure if that is according to GitHubFlow, but it is very simple. |
|
@distantcam hey cam, are you going to take a crack at this? |
|
@JakeGinnivan Yep I've got it mostly working, but some higher priority items have taken up my time recently. Hoping to have this fixed this week. |
|
Done and fixed. Building from a commit with a tag uses that tag no matter what. And can now do historical builds with a detached head. |
|
woot! |
|
@distantcam can you PR next time. Everyone contributing to this project uses PR's even if they have commit rights |
|
@JakeGinnivan Ooh sorry about that. I wasn't aware that was the convention. I'll do it next time. |
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.
The text was updated successfully, but these errors were encountered: