Change branch/versioning system

[tig]

Right now we use Git Flow.

1. main always represents the most recent release of v1
2. develop is the v1 working branch
3. v2_develop is the v2 working branch
4. There is no main for v2
5. the .csproj files do not contain real version information
6. We don't effectively used "pre-release" semver

4 and 5 are problematic for maintaining multiple versions of T.Gui over time (v1 and v2 etc...).

6 makes it hard to determine what version of T.Gui is in use when doing local dev.

Here's my thoughts on addressing this. I've spent a bunch of time digging into this, but am still quite confused anď unclear on the right approach. This Issue is my attempt to write it all down to drive more clear thinking. Help appreciated.

[BDisp]

For 4 how about creating a v2_main branch for the most recent release of v2?
I would love to understand better how workflows/versioning work. Maybe it's a dumb suggestion, but, for 6 and 7, since the GitVersion isn't writing the right version for v2, writing manually the correct on the .csproj before publish it. Sorry if I said bullshit.

[tig]

Sorry if I said bullshit.

Nope, I think your instincts are right.

We'll do the following:

Branches

• Each major release (v1, v2, ...) will have a release branch (v1_release, v2_release, ...). These always match the most recent non-prerelease release (v1.15.9).
• There will be one develop branches for each release branch (v1_develop, v2_develop). Whenever a PR is merged into these branches the library will be published to nuget as v1.15.9-pre<n>.timestamp.
  • Or, perhaps, the version will include the branch name from the PR that was merged?
• Feature and hotfix branches can be created off of these (e.g. v1_fix_9999_...). Each of these can optionally publish to nuget (e.g. v1.16.0-branch.branchname.timestamp).

Version Info

• Version info will be maintained/updated by gitversion
• The release branch's ./GitVersion.xml will automatically be updated to have next-version: set to the next "patch" version by a deploy script (e.g. when v1.15.9 is published from v1_release the script will modify GitVersion.xml to update it to read next-version: v1.15.10. Thus any branches from v1_release will "know" what version they are.
  • This script will ensure v1_develop matches v1_release and then will patch next-version: to v1.15.10-pre0`.
• For the develop branches, each time a merge happens (and publish to v1.11.10-pre...) gitversion /updateprojectfiles` will be called to update the .csproj files with an incremented version (?).

We will use the <VersionPrefix> and <VersionSuffix> tags in .csproj files:

E.g. for v1_develop you'll see:

  <PropertyGroup>
    <VersionPrefix>1.15.10</VersionPrefix>
    <VersionSuffix>pre.$([System.DateTime]::UtcNow.ToString(&quot;yyyyMMdd.HHmm&quot;))</VersionSuffix>
  </PropertyGroup>

I'm still not sure how to update the build automatically. In other projects I used T4 templates. But I'd like to avoid that here.

[BDisp]

Or, perhaps, the version will include the branch name from the PR that was merged?

Isn't possible and enough only the commit id to track?

[tig]

Ok....

develop now publishes on push using 1.14.0-pre.146

I'm backing away from using next-version: in gitversion.yml. Instead, we will use tags.

[tig]

I've renamed the branches. Not sure this is going to work, but I gotta keep trying...

• v1 - was main
• v1_develop - was develop
• v2 - new (v2 release)
• v2_develop - was v2_develop

Sorry for any trouble this causes as I do this.

[tig]

I don't think my plan as stated will work. gitversion is just not flexible enough.

I will need to revert back to having main and develop branches (sorry!).

My next step is to try to use git worktree.

[tig]

Ok, I've "fixed" develop:

• it is v1's "develop" brannch
• pushing to it (or merging a PR) now publishes to nuget (v1.minor.patch-pre.xxx)

Now, I'm going to do a new release of v1 from main which is v1's "release" branch.

I still don't know how to make this work for v2's branches. But I haz ideas.

[tig]

now... on 'main->git merge develop ; git push upstream main`

Will result in a v1.minor.patch-rc.build package being published to nuget

And, if I'm right (fingers crossed), adding a tag (v1.14.0) and then pushing with git push --atomic upstream develop v1.14.0 will result in v1.14.0 being published.

I'll test this asap once the rest of the awaiting v1 PRs are merged.

[BDisp]

@tig I can't build the develop branch. Gives error because of the nuget packages.

\gui-cs\Terminal.Gui\UICatalog\UICatalog.csproj : error NU1100: Unable to resolve 'Microsoft.VisualStudio.Azure.Containers.Tools.Targets (>= 1.19.5)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UICatalog\UICatalog.csproj : error NU1100: Unable to resolve 'SixLabors.ImageSharp(>= 3.0.2)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UnitTests\UnitTests.csproj : error NU1100: Unable to resolve 'Microsoft.NET.Test.Sdk (>= 17.7.2)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UnitTests\UnitTests.csproj : error NU1100: Unable to resolve 'Microsoft.VisualStudio.Azure.Containers.Tools.Targets (>= 1.19.5)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UnitTests\UnitTests.csproj : error NU1100: Unable to resolve 'SixLabors.ImageSharp(>= 3.0.2)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]

[tig]

@tig I can't build the develop branch. Gives error because of the nuget packages.

\gui-cs\Terminal.Gui\UICatalog\UICatalog.csproj : error NU1100: Unable to resolve 'Microsoft.VisualStudio.Azure.Containers.Tools.Targets (>= 1.19.5)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UICatalog\UICatalog.csproj : error NU1100: Unable to resolve 'SixLabors.ImageSharp(>= 3.0.2)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UnitTests\UnitTests.csproj : error NU1100: Unable to resolve 'Microsoft.NET.Test.Sdk (>= 17.7.2)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UnitTests\UnitTests.csproj : error NU1100: Unable to resolve 'Microsoft.VisualStudio.Azure.Containers.Tools.Targets (>= 1.19.5)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]
\gui-cs\Terminal.Gui\UnitTests\UnitTests.csproj : error NU1100: Unable to resolve 'SixLabors.ImageSharp(>= 3.0.2)' for 'net7.0'. PackageSourceMapping is enabled, the following source(s) were not considered: C:\Program Files\dotnet\library-packs, nuget. [\gui-cs\Terminal.Gui\Terminal.sln]

Hmmmm..

Did you try a dotnet clean first?

[tig]

You may need to clear your nuget cache?

dotnet nuget locals all -list
dotnet nuget locals all --clear

Kill all instances of dotnet.exe first.

[BDisp]

Didn't work but I found the culprit that was a the Package Source Mapping that was set has * nuget. Removing it resolved the issue. Thanks for your help.

[tig]

Didn't work but I found the culprit that was a the Package Source Mapping that was set has * nuget. Removing it resolved the issue. Thanks for your help.

Is that default? Do you know?

[BDisp]

I'm not sure because once I needed to add others source mapping but I've gotten issues with others projects and I removed all and only keep the nuget checked. I haven't more problems until today after started merge the Terminal.Gui. I deleted the .nuget folder on my user folder, but couldn't again restore the packages. After I removed and empty the Package Source Mapping the build start to restore all the project nuget packages. Perhaps was some issue after updated to the latest VS2022 version 17.7.3.