(totalcommander) Remove padding 0 in version number

[pascalberger]

Current version number of the Totalcommander package is 9.00.01, which can lead to problems with tools (eg. ProGet cannot handle this properly). Leading zeros in the version should be removed.

[AdmiringWorm]

@pascalberger isn't this something that should be reported to the ProGet developers (and other tools with the problems)?
IMO they should be able to handle versions with leading zeroes

[pascalberger]

@AdmiringWorm I already did. Their response:

Unfortunately that package uses an unsupported versioning scheme, so you’ll need to rebuild it to the correct scheme to use it within ProGet. I would recommend to comment on the package for the author to see it.

NuGet has not supported that in quite a while, so we need to redirect in situations like that.

I assume their handling Chocolatey like NuGet and therefore normalize version number because of this breaking change in NuGet 3.4.

[AdmiringWorm]

I see, I thought nuget still supported that versioning scheme.
hmm, maybe we should change it to forcing it to using [version] then back to a string afterwards.
Unless I'm mistaken, I think that would be a quick way to fix leading zeroes.

[ferventcoder]

This seems like something that should be filed in choco's repo to get fixed.

[jberezanski]

There are other packages on Chocolatey.org that use leading zeroes (for example, https://chocolatey.org/packages/dotnet4.6.1). Do we really need to be compatible with ProGet?

(In contrast, MyGet handles such version numbers just fine and they quickly fixed issues I encountered in the past, such as trimming zeroes or stripping the fourth version segment.)

[pascalberger]

I don't think it is only about compatibility with ProGet, but also with NuGet.Core releases >= 3.4. As soon as choco would update to an up to date NuGet.Core release I think all those packages no longer would work with choco either. For this I'll also create an issue in choco repo as @ferventcoder suggested.

[jberezanski]

I see. So, are you thinking about a policy change on chocolatey.org (tightening the rules for package versions + removing/rewording the guideline that package versions should match the actual software versions) or working around NuGet.Core problems with such versions in choco.exe?

There is another point of incompatibility with NuGet - the additional metadata in nuspec (which breaks NugetPackageExplorer, for example). Assuming modern NuGet.Core has problems with it too, forking and patching will be inevitable anyway.

However, @ferventcoder do I recall correctly you were planning on moving away from NuGet.Core altogether?

[pascalberger]

Yes, this is what I've suggested in the issue created in the choco repo: chocolatey/choco#1174.

But I think the main discussion is if the goal is to have maximum compatibility with NuGet tools, or if Chocolatey should seen as an own tool with different specification (which IMHO but also should include stuff like haven an own xsd schema, etc). The bigest advantage with having maximum compatibility with NuGet is that it's more likely to get a broader ecosystem of tools working with Chocolatey, eg. ProGet. I expect them not to make changes to support such differences in Chocolatey to NuGet, but instead just blame Chocolatey to be not compatible, which actually is not really Chocolateys problem, but also doesn't help adaption, especially in an enterprise environment where there are not really much options for private feeds, and all of the existing ones have their own different issues.

[ferventcoder]

Likely implementing normalized versions on chocolatey.org as well.