Create nuget push script for new packaging model

[rockfordlhotka]

We now generate nuget packages during build, and the packages end up in /csla/bin/packages.

The /csla/nuget directory can largely be removed at this point, other than that we still need a script (I think?) to push the packages to the nuget server.

This can be powershell or bash - either is fine with me. I personally use bash, but the existing script is powershell.

We should now be using the dotnet nuget push command instead of the raw nuget.exe tool.

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-push

[luizfbicalho]

I'm not a specialist in the github build, but shoudn't this push be in the end of the github build? In azure devops I have this

 - task: PublishSymbols@2
    displayName: Publish symbols path
    continueOnError: True
    inputs:
      SearchPattern: NugetPackages\**\*.pdb
      SymbolServerType: TeamServices
  - task: NuGetCommand@2
    displayName: NuGet push
    inputs:
      command: push
      searchPatternPush: $(Build.ArtifactStagingDirectory)/../**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg
      feedPublish: XXXXXXXXXXXXXXXXXXXX
      allowPackageConflicts: true

[StefanOssendorf]

Yeah. This should be done automatically when a release is created. That's my github action for my source gen publish: https://github.com/StefanOssendorf/Csla.DataPortalExtensions/blob/master/.github/workflows/nuget-release.yml

[rockfordlhotka]

Do you have a release branch or something like that?

We'd need multiple - a release off v8.x, main, and perhaps other maintenance branches.

[luizfbicalho]

In my other framework I have a release and a branch for the current version (.NET 8.0) one release and branch for each previous version (3.1, 5.0, 6.0,7.0)

this way the version.json is changed on each branch to control the nuget release version

maybe there is another approach to this

[rockfordlhotka]

This is a learning experience for me. I have been keeping the git branching model very simple for years, relying on tags to mark releases.

It seems to me that using branches for this would require a branch for each prerelease as well as release - well, really two branches per prerelease and release?

That seems like it could be a lot of branches?

[luizfbicalho]

I have one version for each .net version

One that is the current version, for example now I'll create a new branch Version 8.0 and the current will turn to 9.0

[StefanOssendorf]

At work we are using one branch per version (including pre-release). That means we have a branch release/v1.0 which gets a tag v1.0.0-pre.0 which is a pre-release 0. We add as many pre-release tags as necessary until we deem a tag stable/tested enough to be released. For a release a put a new tag on the same commit as the last pre-release tag with v1.0.0 to release that version. The tags also trigger builds & releases (in azure devops) for automatic deployment. To use the tags we use minver as a tool but I'm very certain Nerdbank is capable of that, too.