Add latest version to releases

[Epictyphlosion]

Now that 7-zip ZS has been caught up with mainline 7-zip, I don't see any reason why version 22.01 shouldn't be in the releases page.

[mcmilk]

The current build does not work thats why it is so.

[mshedsilegx]

Does this help ?
#274
Patch in: #274 (comment)

[mcmilk]

I did a pre-release today ...

[mshedsilegx]

This is much appreciated.

[mcmilk]

I don't know winget repo?

[mcmilk]

I had no idea what winget is ... it look like some package manager for windows. I did't create some packet for it ?

[mcmilk]

Now that 7-zip ZS has been caught up with mainline 7-zip, I don't see any reason why version 22.01 shouldn't be in the releases page.

DONE ;)

[mcmilk]

I am not ...

[Speed4Trade-Admin]

The problem with winget is the different version number:
22.01 ZS v1.5.5 R2
vs
22.01-v1.5.5-R2
If they don't match exactly, the update is shown again and again.
One version comes from the setup which is adding the version in the registry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\7-Zip-Zstandard

[mcmilk]

All my releases are done this way:
19.01-v1.2.3-R1
20.04-v1.3.4-R1
22.01-v1.5.1-R1 22.01-v1.5.1-R3 22.01-v1.5.1-R3
22.01-v1.5.5-R1 22.01-v1.5.5-R2 22.01-v1.5.5-R3
And so on .... First number is 7-Zip, the second number Zstandard, in the end my own release number.

You can look into the tag history.

[thomass4t]

Could the header file "7zVersion.h" be the source of the problem?

#define MY_VERSION_NUMBERS "22.01 ZS v1.5.5 R2"

There is an additional "ZS"

[mcmilk]

These are two sources.

This header file 7zVersion.h has since it's beginning the other naming - it's used for the about box and other things.
The tag is used for the source code at github.

This winget thing should always use the same source for it's comparison.

[thomass4t]

I think the mistake is located there:
https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/mcmilk/7zip-zstd

I dont know where they pull the version number from.

[thomass4t]

Here is some information how it works:
microsoft/winget-cli#2613

There is also a github action available to publish new versions and thus don't rely on web scraping and similar stuff.

[vedantmgoyal9]

Hello, the automation gets the version from the GitHub releases tags with the starting v removed from it. So it is something like:
v22.01-v1.5.5-R2 - starting v => 22.01-v1.5.5-R2.

Also, yes, I do have a GitHub Action vedantmgoyal2009/winget-releaser which can be run as a CI job, if the maintainer is comfortable with.

[thomass4t]

I would recommend to either use a GitHub Action or just keep the versions in sync with the header file:
#define MY_VERSION_NUMBERS "22.01 ZS v1.5.5 R2"

[mcmilk]

Hello, the automation gets the version from the GitHub releases tags with the starting v removed from it. So it is something like: v22.01-v1.5.5-R2 - starting v => 22.01-v1.5.5-R2.

This looks okay.

Also, yes, I do have a GitHub Action vedantmgoyal2009/winget-releaser which can be run as a CI job, if the maintainer is comfortable with.

Yes, I have no problem with that :-)

[mcmilk]

The version string from the header can't be used for this then ...

[mcmilk]

The string "22.01 ZS v1.5.4 R4" within the header is not technical ... it's a define I used for some about box.
@youk - please stop bugging me because auf this string. I don't want some - there ....
The winget package should no use this string ... thats it.

[youk]

You may do whatever you please. Nobody is "bugging" you. Ciao.