[Package Request]: `Element.Element.Nightly`

[RokeJulianLockhart]

Package Requested

• I would like someone else to build the manifest.
• I would like help so I can submit the manifest.
• I have performed a search and couldn't find this package.
• I have checked that the installer for this package is not a standalone or portable executable or a .zip file
• I think there is a new version available and I have provided the URL.

Please provide the following information

Download Page URI	https://element.io/download#:~:text=Element%20web-,Desktop,-.
Publisher	New Vector Limited
Package Name	Element.Element.Nightly
Description	All-in-one secure chat app for teams, friends and organisations.
Package Version	https://github.com/element-hq/element-desktop/releases/tag/v1.11.69-rc.0
Installer URI	https://packages.element.io/nightly/install/win32/x64/Element%20Nightly%20Setup.exe

[Trenly]

Are there any URL's to nightly versions which are retained? Having a vanity url here will cause many issues, since the package would need to be updated every day with the new SHA256

[vedantmgoyal9]

That can be done by the automation?

Edit: @wingetbot can also do it, but I doubt if it runs daily or weekly.

[Trenly]

That can be done by the automation?

Edit: @wingetbot can also do it, but I doubt if it runs daily or weekly.

What if you take your automation offline for anfew days? What if the package starts getting validation-domain errors that require a MSFT engineer to look into every single new release every day (waivers can’t be used, since waivers are version specific)?

If theres static URLs to previous versions its not a problem, the package just won’t be the latest. With a vanity URL though, users would get a hash mismatch error.

Where possible, vanity URLs should be used for production releases only. Even then, it is much better to have a versioned URL than a vanity URL in most cases

[vedantmgoyal9]

The path in the validation file is version specific but it's applied to the whole package.

[Trenly]

The path in the validation file is version specific but it's applied to the whole package.

I disagree. If that were the case, then https://github.com/microsoft/winget-pkgs/pull/38412/files would not have been necessary to fix a Validation-Domain error

[vedantmgoyal9]

Oh, it looks like they have made changes in the system. As far as I know, the .validation was automatically applied for package updates.

Anyways, thanks for correcting me.

[lychichem]

The real problem for vanity URL is not automation, it's we cannot make end users update to latest version by running winget upgrade.

[Trenly]

The real problem for vanity URL is not automation, it's we cannot make end users update to latest version by running winget upgrade.

Winget upgrade would still work, as long as the package is kept up to date and the version changes with every build?

[lychichem]

The real problem for vanity URL is not automation, it's we cannot make end users update to latest version by running winget upgrade.

Winget upgrade would still work, as long as the package is kept up to date and the version changes with every build?

No, because any old version will be deleted by wingetbot in this situation, so users with older versions installed cannot get any update info by running winget upgrade. I used to do same thing to VClibs, and got this reply from one of the moderators.

[Trenly]

The real problem for vanity URL is not automation, it's we cannot make end users update to latest version by running winget upgrade.

Winget upgrade would still work, as long as the package is kept up to date and the version changes with every build?

No, because any old version will be deleted by wingetbot in this situation, so users with older versions installed cannot get any update info by running winget upgrade. I used to do same thing to VClibs, and got this reply from one of the moderators.

That isn't how winget works though; Winget checks the control panel for currently installed versions and compares against the versions available. You can see that it works fine for many packages like the GeoGebra packages. The reason that no update info would be found in some specific packages where the DisplayVersion key isn't set by the installer, or where the version is the same.

I think that we have to be careful not to generalize, since each package is unique in its own way

[vedantmgoyal9]

@Trenly, It may NOT be a good idea but still, I think the packages which have vanity URLs and are ignored by @wingetbot, we can update them through a GitHub Action.