Add property to always expose commits since last version #701
Conversation
|
@onovotny: Could you please also document the new variable in variables.md. Otherwise it LGTM, but I would prefer to have @JakeGinnivan a look at this before merging. |
|
@pascalberger updated |
|
Just one comment... Does CommitsSinceLastVersion correctly described the intention? Would CommitsSinceLastRelease, CommitsSinceLastReleasedVersion not be more descriptive of the intention? For instance, in my workflow, I don't tag until I release a version to "somewhere". I could be barking up the wrong tree, but thought I would put it out there. |
|
I agree with @gep13. The word |
|
I'm open to changing it, naming is hard! Given how many touchpoints it is though, I'd rather rename it only once before updating this PR, so we need a decision on the right name. |
Makes sense to me. Options:
Vote away.... My preference would be 2. |
|
I think of those four, I'd go with 2 as well. GitVersion doesn't require tags, so 4 might be a red herring. 3 is just longer :). Between 1 and 2, I'm indifferent. |
|
Yes, although in my workflow, CommitsSinceLastTag makes things crystal clear, the adding of a Tag is just one way to assert the Version Number of your repository, so it wouldn't work across all the options within GitVersion. |
|
4 is for me also no option for the mentioned reasons. Otherwise not really sure, not all versions might be released so there might be a difference between Version and Release. |
|
Agree that not all versions might be considered "released," which is why I initially just went with "since last version". |
|
The problem I have with Version is... what version are you talking about? i.e. 2.0.1-beta0001 is a version, but so is 2.0.1. If my understanding is correct, the counter that you are adding in would give the commits between two "releases" of an application, i.e. 2.0.1 and 2.0.2, or 2.0.2 and 2.0.3. If that is not the case, then I am definitely barking up the wrong tree. Really the variable would need to be called something like:
but I think that might be a bit long :-D |
|
In my case, I use 2.0.1-beta1 as the version and have n builds of it. So it'd be 2.0.1-beta1-build001. That said, I believe the logic to do the commit count ignores pre-release tags. So when I eventually have 2.0.1-beta1-build102 and ship it, then I bump to 2.0.1-beta2. The commit count though would be 102, not back to 0 or 1, so the next build would be 2.0.1-beta2-build103 or some such. Ideally I'd like the commit counter to reset but for my needs, I'm ok with it resetting only between non-pre-releases. |
so that I am clear, how exactly are you bumping this? |
|
I'll do it one of two ways: either tag 2.0.1-beta2 or update the next-version in the config to be 2.0.1-beta2 |
|
I don't think there's any "automagic" way for GitVersion to know when to bump my beta versions as it depends on whatever I feel like releasing. |
|
ok, so not through a commit message or anything like that? |
|
I've never used a commit message for releasing anything :) |
|
Hmm, will be interesting to hear @JakeGinnivan thoughts on this one. I might well be over thinking it 😄 |
|
The commit counting stuff is referred to internally as the VersionSource, and we take the oldest source to do commit counting (this means that it might not be exactly correct in some scenarios, but it means that the count doesn't reset randomly). This entire workflow is something I have not got my head around yet so feel free to point out things I have missed. @onovotny this is to start moving towards your The way I see this would work and the terms I think I would use to describe it. When using GitFlow I want to manually control the SemVer in a continuous delivery way but want each publish the NuGet package for each build. The SemVer will be the same for each build so I want to promote the Does the terminology/workflow sound right? |
|
So given the naming choices, As to the rest of it, yes, I believe exposing this property works towards After renaming, are you good with it being merged in? |
| "NuGetVersion":"3.0.0-beta0001", | ||
| "CommitsSinceLastVersion":1, | ||
| "CommitsSinceLastVersionPadded":"0001", | ||
| "CommitDate":"2014-03-06" |
There was a problem hiding this comment.
Is this the date of the head commit or the source version commit?
There was a problem hiding this comment.
Oh, this isn't new. Hrrmm
There was a problem hiding this comment.
Yeah, it wasn't new, just fixing it in the docs
|
Yeah, happy for it to be merged. As long as the version source thing makes sense to others, just making sure the internal name/concept translates well as an external concept/name |
|
That's been the hard part of this....coming up with a name that conveys its meaning and doesn't overload other words. |
|
@JakeGinnivan @onovotny I think the term |
|
Yip, totally agree, makes sense to me 👍 |
|
👍 |
Add property to always expose commits since last version
There are many places where there's a need for an incrementing number per version. This can be thought of as the "build number", but that term is overloaded. Instead, I just called it CommitsSinceLastVersion to let users do what they need with it.
In our case, I'm using it as the "Patch" version for a continuous deployment scenario where semVer isn't supported -- AppxManifest in the store. I need something like 2.0.101.0. I can't use the continuous deploy mechanism as these are actually beta's. The FullSemVer would be 2.0.0-beta4. If I use CD, then it'd be 2.0.0-beta101 and that's not what I want. I don't really want to update the beta per build. It's similar to wanting 2.0.0-beta4-build101, but I'm ok with the number coming from 2.0.0 and not reseting at "beta 4".