Publish installer URLs with vXX.YY.ZZZZ version format

[SSLbits]

There's some confusion caused by the vanity URLs for the installer downloads.
Could you also publish installer URLs somewhere on the forum or on the web site that include the version in the XX.YY.ZZZZ format: https://www.xyplorer.com/download/XYplo ... nstall.exe

I'm attempting to help sort out an issue with the winget package manifests for XYplorer. Currently, the manifests are pointed to the vanity URLs and contributors are accidentally trying to publish beta versions as official releases and the checksum hashes in the manifests fail when checked against the version that gets downloaded. I've created two issues in github for the latest maintenance release:
https://github.com/microsoft/winget-pkgs/issues/211377
https://github.com/microsoft/winget-pkgs/issues/212115

I also have a pending merge request with what I believe will resolve the issue of XYplorer updates consistently failing to install or update correctly when using winget:
https://github.com/microsoft/winget-pkgs/pull/212388

I hope to achieve this by specifying this URL for the InstallerUrl in the manifest: https://www.xyplorer.com/download/XYplo ... nstall.exe for the 26.70.0600 maintenance release.

Publishing the installer URLs on the site/forum that are publicly accessible would clear up some confusion and streamline publishing the updates for the Windows Package Manger.

[admin]

You can find versioned packages in the Beta thread: viewtopic.php?p=226689#p226689

Also note the freezer: https://www.xyplorer.com/freezer.php

[SSLbits]

Thank you for the reply.
I was hoping to see published URLs that link directly to the installer executable rather than a .zip archive. But I think what would be especially useful are URLs with the explicit maintenance release version in the URL.
For example, at the time of publishing 26.70.0500 on the 27th of December, that installer package would point to `free-zer/26.70/xyplorer_full.zip`but after the 10th of January since publishing 26.70.0600 the same URL would contain `free-zer/26.70/xyplorer_full.zip` but the file that is downloaded would be different and have a different hash checksum than what was published.
There's currently a pull request with the following installer attributes in the manifest:
PackageVersion: 26.70.0600
InstallerUrl: https://www.xyplorer.com/download/XYplo ... nstall.exe
InstallerSha256: F8EDDA0440093A987A12C12C6351F64E4BF85E3C03901E569C9D2FD00E3E1699

However, as of this writing, the file that it actually downloads is a different package version (I believe it's the 6.70.0606 beta) and the checksums are different. This will result in a failure to install the application when anyone tries to download and install or upgrade XYplorer using winget.

I feel that the vanity/variable URLs are causing ambiguity and confusion among the contributors trying to manage XYplorer updates in the Windows Package Manager. It would be very helpful if there were also precise versions available in the URL provided by you, the software vendor, for contributors to reference when building the manifests. This would also be helpful for end users who are trying to install or update XYplorer with winget when different maintenance releases are available that would also pass the checksum validation step so that the files downloaded match the checksum published in the manifests.

I'm new to contributing to this project, so I could try to see if it would be possible to configure the manifests to point to the .zip file with the nested installer file and unpack it prior to installing, but it would greatly simplify things if you were able to provide a published URL and checksum for releases rather than have contributors have to find this information for themselves:
PackageVersion: 26.70.0600
InstallerUrl: https://www.xyplorer.com/download/XYplo ... nstall.exe
InstallerSha256: C3AA9C002F377CC7DCA9B345A3347E73F65AEAC3BC39FBDFAE5B4B23B5AFAF1A

Thank you so much for reading and considering this.

[admin]

XY has a well-working self-updating mechanism (Help | Online Support | Check for Updates). There is no point in adding such a heavy parallel path.

[SSLbits]

Would it be possible for the freezer URLs to include verbose maintenance version numbers? I don't want to create unnecessary work. I'm just trying to clear up some confusion.

Again thank you for your consideration and time.

[admin]

I don't think it's necessary.

[SSLbits]

Alright. Thank you for your consideration and taking the time to respond.

[bdeshi]

XY has a well-working self-updating mechanism (Help | Online Support | Check for Updates). There is no point in adding such a heavy parallel path.

since xy might arrive in Linux on the future, i just wanted to note that most power users expect updates to be managed centrally by a package manager (like what winget is trying to do); in app mechanisms kind of go against the flow, from the pov of a Linux user.

[Horst]

since xy might arrive in Linux on the future, i just wanted to note that most power users expect updates to be managed centrally by a package manager (like what winget is trying to do); in app mechanisms kind of go against the flow, from the pov of a Linux user.

I call myself a Windows Power user
but I prefer in-app updates like the one in XY.
There are no configuration needed for any other tool.

The only exception from this are users in a corporate environment
with locked applications and centralized updates.

[SSLbits]

I have less concern so long as the URLs still actually exist and they match the maintenance versions and we can predictably guess them. Having them published by the author would help clear up some confusion on the winget/github side, but that's really an issue to be tackled there. I don't want to make demands of the software author to better support a system that they don't control.

I've been using the in-app update feature since I have a lifetime license and have it installed on a few machines, but prefer being able to update apps on windows machines with winget. If you share that preference or just like to see more options available, please react to or comment on my PR or issue in github:
https://github.com/microsoft/winget-pkgs/pull/212722
https://github.com/microsoft/winget-pkgs/issues/212115