csq pack package name not same as provided version

[Basyras]

Using:

Clowd.Squirrel v3.0.210-g5f9f594 csq v3.0.210-g5f9f594

To reproduce:

When calling: dotnet csq.dll pack --packId My.App --packVersion 0.1.0-myFeature.1+29 --packDirectory <publishFolder> --csq-sln=<solutionPath> Output package name will be My.App-0.1.0-myFeature.1-full.nupkg

Issue/Question:

EDIT: I believe there is a bug excluding the build number part of the semantic version +29 (version inside the package is the same as provided: 0.1.0-myFeature.1+29)

[caesay]

Thanks for the feedback, I'll have a look

[Basyras]

I haven't looked inside your code but I just find out if you do:

string version = "0.1.0-feature.1+23";
var semVer = SemanticVersion.Parse(version);
semVer.ToString() //returns 0.1.0-feature.1
semVer.Metadata //returns 23

so if you use SemanticVersion.ToString() perhaps you should change it.

If you point me to correct file.cs I could try make PR if you are busy with other things.

[caesay]

This will likely need to be updated in a number of files as there are a few places SemanticVersion is used. let me ask - do you really need the build metadata included in the filename? What is your usecase?

The reason I ask is that parsing the file name of releases is already getting much more complex as I am currently adding support for different CPU architectures (win-x86, macos-arm64). The architecture also needs to be stored in the filename after the version, so right now it would actually look like this My-Cool.App-0.1.0-myFeature.1+29-win-x64-full.nupkg.

We are also mostly trying to stay compatible with the older version of Squirrel which of course does not support semver2 at all, but does support release labels. So in Squirrel.Windows, without the +29, the version would get parsed as 0.1.0-myFeature.1-win-x64 which is fine, whereas with the +29 it will just break.

[Basyras]

I am using Nuke and I am calculating the build number via GitVersion (it calculates SemVer 2 from git history).

When doing csq pack in feature branch GitVersion outputs mentioned version in this format 0.1.0-<branchName>.1+<buildNumber>. csq hapilly accepts this version but will ignore the buildName in outputted package.

I tried manually adding the +buildNumber to the outputted package file and to the RELEASES file but all changed files and records in RELEASES keeps being deleted when creating new version.

The use case was that when providing setup to the testers it is visible from the setup name what feature and what commit they are testing.

Currently using workaround: when calling csq pack I provide changed desired version from 0.1.0-<branchName>.1+<buildNumber> to 0.1.0-<branchName>.1plus<buildNumber> It seems do the trick so far. Perhaps csq could do the same. If you dont want to support SemVer2 at all (or at least the metadata +number part) I would suggest at least validate provided version string and return error code from csq pack when provided string has this metadata.

Not sure what backward combability you want to achieve. This is not breaking change if you migrate from original squirrel to Clowd.Squirrel right? But rather the other way around probably. Since no-one used this metadata in version in old squirrel (since they could not) supporting it here is not breaking change I think?

Question:

Is the new way how to detect SquirrelAwareVersion already breaking change? Also when you use dotnetcore or dotnet5+ this is breaking change for Windows.Squirrel too right?

tl;dr

not big issue for me since I found workaround, we could save headaches from others by validating the version string.

[caesay]

I will have a look at this and see what I can come up with. The kind of compatibility I'm looking to preserve is when an installed app is updating from Squirrel.Windows to Clowd.Squirrel, so the packages that Clowd.Squirrel produce need to still be mostly compatible, and new features will ideally be ignored by Squirrel.Windows (and even older versions of Clowd.Squirrel)