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.

[dodexahedron]

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.

Whatever you want to happen, I'll make happen in #3558, since this is central to the goal of that issue.

Auto versioning? Sure. Including git commit in the package and/or library metadata? Sure. More flexibility of when and how release builds are performed and how they are/can be deployed? Yup.

All in the goal of that. So any wish list items around builds, go ahead and drop em in #3558. 😊

[dodexahedron]

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.

I've already solved that in my working branch. The problem is indeed the source mapping but only because it clears all and uses an unbounded wildcard.

The appropriate fix is to not clear, and to just specifically add mappings to packages we are dependent on. That configuration can actually be auto-generated by a tool I picked up a while back.

Honestly, Visual Studio should really do that by default to the local nuget config, whenever packages are changed. But it doesn't. Because reasons, I guess.

In any case, it's easy enough to do and I've already got it in there. Do whatever you gotta do to make it work for you in the interim of course, and a fixed config will just come in that PR.

The easiest thing for you to do would honestly be to delete and git ignore the nuget.config file in your working tree and you're all set. Don't commit the delete. And the git ignore for the file belongs in your user, global, or system git config - not the repository config. Otherwise you'll affect CI woth it.

[dodexahedron]

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?

Default config on a new install of nuget as part of visual studio, PowerShell, or .net SDK is wildcard, as well.

Main difference between ours and built-in is the name of the source, which is ALMOST the same, but not quite.

It's still considered best practice to have a nuget.config in the solution root, though, so my intent in #3558 around that is have it act with a lighter touch and just add, not replace people's config. Right now it unconditionally wipes and replaces theirs for any msbuild process that runs at or below the level of thst config file unless explicitly told to ignore it.

Partially a dependency-imposed smell that's no longer relevant, but honestly mostly just bad design of nuget itsrlf, IMO. It literally walks the directory tree all the way to root of the file system hierarchy it is in and takes the first nuget.config it finds no matter if your solution is 30 directories away from root. Found that out a long time ago when troubleshooting nuget problems in another project and I moved the nuget to the parent directory above where the solution was, as a quick and easy way to hide it from nuget on restore. NOPE! It found it because of that behavior, ehich is documented as how it works.

Anyway, yeah...

I've got a permafix for it coming in #3558. Wrote it weeks ago, actually. 😅