Add preview information to version number #1474
Conversation
|
Given that we aren't using a more complicated branching strategy here, like git flow, this seems like an OK change to make. However, if we do actually want to release a prerelease of some sort (for example to get a .NET Core compatible version on NuGet), how would we do that? |
|
Right - my goal here was explicitly to get a .NET Core compatible nuget package on nuget.org. This didn't really solve that problem, you're quite right. Now we have an 0.24.2-gwhatever version. Bleh. @AArnott what's up with this version number strategy you have here? I want to make 0.25 prereleases, and have a version strategy for 0.24 hotfixes. How should this work? |
|
The basic philosophy behind NB.GV is that every git commit should produce a build with a unique version stamp. That way, any binary can be traced back to its exact source code trivially. In addition when it comes to NuGet package versions, this ensures that NuGet caches don't start giving ghostly problems where you have several commits in your repo that all build the same package version, only one of which can exist in your nuget cache at once and thus you think you're getting one build installed for testing but you actually get another instead and it takes you hours of debugging before you realize it. So now lets analyze each concern you brought up:
The
That's the default behavior in order to ensure each build has a unique version. Yes, that means you'll ship 0.25.14-beta and later ship 0.25.40-beta, and finally when you ship an 'RTW' release it will be 0.25.55. And servicing it will make it 0.25.56, 0.25.57, and so on. If you really don't like this incrementing of the 3rd integer though, NB.GV recently advanced to offer you another option as documented here. Specifically, you can take control of all 3 version integers, and move the git height to the prerelease tag, so it looks like |
|
@AArnott You mentioned 0.25.14-beta and 0.25.40-beta, but how do we actually get that -beta tag on a release? |
|
Just add it to the {
"version": "0.25-beta"
} |
|
And that would know to insert the patch version in the correct place? Edit: Based on the docs, looks like the answer is yes! |
|
@ethomson I like the idea of including the height in the prerelease tag, seems to be best all around solution, because you get full control over all 3 parts of the version number, and you get the auto-incrementing part as well. |
|
Agree that we don't want to revert to 0.24.0 - as you both pointed out, that's definitely not solving the problem. We want to keep 0.24.teeny for actual hotfixes to the 0.24 release. I do prefer to be able to release 0.25 as 0.25.0, mostly just because I'm old school. Thanks for the insight here @AArnott . |
27d0411 to
3bb9850
Compare
|
@ethomson If you intend to ship 0.25.0, then you shouldn't build 0.25.15-preview leading up to that. So your version.json change should set version to |
|
For example, your PR is building |
3bb9850 to
5d4b761
Compare
|
Awesome, thanks! |
|
Oh, from the build break I see we're still using NB.GV 1.6.25. The ability to move the |
90ccb4d to
49963c2
Compare
49963c2 to
b000adf
Compare
| @@ -7,6 +7,10 @@ | |||
| </PropertyGroup> | |||
|
|
|||
| <ItemGroup> | |||
| <PackageReference Include="CodeGeneration.Roslyn.Attributes" Version="$(CodeGenerationRoslynVersion)" /> | |||
| <PackageReference Include="CodeGeneration.Roslyn.Attributes" Version="0.4.11" /> | |||
There was a problem hiding this comment.
Instead of modifying these values here and other places, you should update the Directory.Build.props file instead.
There was a problem hiding this comment.
Oh huh. Thanks for catching this, I just ran update via VS.
There was a problem hiding this comment.
Yeah, the tooling inside of VS doesn't really understand the Directory.Build.props/targets files yet. 😖
There was a problem hiding this comment.
Good to know. I fixed it up manually, should be good now.
| </ItemGroup> | ||
|
|
||
| <ItemGroup> | ||
| <PackageReference Update="Nerdbank.GitVersioning" Version="2.0.37-beta" /> |
There was a problem hiding this comment.
This is already referenced in the Directory.Build.props file, so you should update that one reference and remove the ones you added to the individual project files.
b000adf to
39f2089
Compare
LibGit2Sharp/LibGit2Sharp.csproj
Outdated
| @@ -32,7 +32,7 @@ | |||
| </ItemGroup> | |||
| <ItemGroup> | |||
| <PackageReference Include="LibGit2Sharp.NativeBinaries" Version="[1.0.185]" PrivateAssets="contentFiles" /> | |||
| <PackageReference Include="SourceLink.Create.GitHub" Version="2.0.2" PrivateAssets="all" /> | |||
| <PackageReference Include="SourceLink.Create.GitHub" Version="2.1.2" PrivateAssets="all" /> | |||
There was a problem hiding this comment.
Sorry, didn't notice this before, but the dotnet-sourcelink-git tool reference below should be bumped to 2.1.2 as well to match this change.
Our new version numbering system is quite clever and tries to advance the teeny version number automagically. Instead of versioning prereleases as `0.25.x` where `x` is monotonically increasing, version our prereleases as `0.25-preview`. This is roughly what our previous strategy looked like.
39f2089 to
d46136a
Compare
|
@ethomson I went ahead and fixed the |
|
I've restarted the mac build a few times, but it seems Travis is having connectivity issues again on their macs... |
|
Awesome, thanks @bording |
|
Hrmf. Well, I don't know why the Mac build isn't working, but it's unrelated to this, so I'm going to merge it. Thanks again for your help y'all. |
Change the version numbers to 0.25.0-preview-nnnn, which is basically in line with our old preview number strategy.