microsoft
KDE.Dolphin.Nightly
Rectification of the version of KDE.Dolphin.Nightly, and replacement of the URL for the installer with a version that is much more easy to maintain, but shall not cause submission of invalid installers.
This should allow the improvements that have been submitted to http://github.com/microsoft/winget-pkgs/issues/30233 to be merged.
- [X] Have you signed the Contributor License Agreement?
- [X] Have you checked that there aren't other open pull requests for the same manifest update/change?
- [ ] Have you validated your manifest locally with
winget validate --manifest <path>? - [ ] Have you tested your manifest locally with
winget install --manifest <path>? - [ ] Does your manifest conform to the 1.0 schema?
Note: <path> is the name of the directory containing the manifest you're submitting.
Microsoft Reviewers: Open in CodeFlow
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hello @BEEDELLROKEJULIANLOCKHART, The package manager bot determined that the metadata was not compliant.
Please verify the manifest file is compliant with the package manager 1.0 manifest specification. Make sure the ID is of the form publisher.appname and that the folder structure is manifests\partition\publisher\appname\version. Note: The path and "PackageIdentifier" are case sensitive. Be sure to use a tool like VSCode (https://code.visualstudio.com/) to make sure the manifest YAML syntax is correct.
You could also try our Windows Package Manager Manifest Creator Preview.
For details on the specific error, see the details link below in the build pipeline.
PackageVersion needs to be according to the one in control panel otherwise it might cause issues while upgrading.
http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959160630.
@KaranKad, within http://binary-factory.kde.org, all entries are versioned consistently. Are you sure that replacement of it with that shall be assistive? I am also not sure of where that value is from.
For evidence of this, please do observe the submitted metadata that is for other software that has been created by KDE e.V: http://github.com/microsoft/winget-pkgs/issues/30233 (master-0271), and: http://github.com/microsoft/winget-pkgs/issues/30234 (master-1255), and: http://github.com/microsoft/winget-pkgs/issues/33704 (master-1347), and: http://github.com/microsoft/winget-pkgs/issues/33705 (master-0426), and: http://github.com/microsoft/winget-pkgs/issues/33706 (master-0164), and: http://github.com/microsoft/winget-pkgs/issues/33709 (master-0928), and: http://github.com/microsoft/winget-pkgs/issues/33710 (master-0924), and: http://github.com/microsoft/winget-pkgs/issues/33711 (master-0747), and: http://github.com/microsoft/winget-pkgs/issues/33712 (master-0743), and: http://github.com/microsoft/winget-pkgs/issues/33713 (master-0741), and: http://github.com/microsoft/winget-pkgs/issues/33715 (master-0073), and: http://github.com/microsoft/winget-pkgs/issues/33716 (master-0338), and: http://github.com/microsoft/winget-pkgs/issues/33719 (master-0338), and: http://github.com/microsoft/winget-pkgs/issues/33721 (master-0936), and: http://github.com/microsoft/winget-pkgs/issues/33722 (master-0936), and: http://github.com/microsoft/winget-pkgs/issues/33725 (master-0931), and: http://github.com/microsoft/winget-pkgs/issues/33726 (master-0785), and: http://github.com/microsoft/winget-pkgs/issues/33727 (master-0744), and: http://github.com/microsoft/winget-pkgs/issues/33729 (master-0436), and: http://github.com/microsoft/winget-pkgs/issues/33730 (master-0932), and: http://github.com/microsoft/winget-pkgs/issues/33735 (master-0741), and: http://github.com/microsoft/winget-pkgs/issues/33736 (master-0027), and: http://github.com/microsoft/winget-pkgs/issues/33737 (master-0744).
Consequently, usage of the value that you have proposed (master-b6ec4b1c9, rather than master-271) for this package surely shall not be beneficial.
It's the value they are putting in the Add and Remove Programs table, which is how winget knows to upgrade something (given that it's text and not a number I don't know if the comparison algorithm will work correctly here, but that's how it works). We need to use that value for PackageVersion.
What is an ARP entry?
ARP == Add and Remove Programs table. It's winget's source of truth for all of the non-MSIX apps installed on the machine, and how it determines whether or not an upgrade is necessary. We need the version number to be whatever is in that table (until schema 1.1).
The reason that I have specified "/lastSuccessfulBuild/" is because if "/lastSuccessfulBuild/" is used, the logic that is required for automatic replacement by new versions is much more simple, because the name of the version is part of the filename, so also switching directories is quite silly. This should not prevent operation any current functionality of winget.
Using lastSuccessfulBuild breaks the links, and a find and replace on the link will fix all instances of the number anyway, so I don't know why having it in two places in the string is worse than having it in one place.
for anyone who cares: Jenkins has a pretty good API, I just wrote a little Python and can get all of the latest versioned nightly links. Shouldn't be too bad to automate this.
I know @vedantmgoyal2009 has plans to automate it according to https://github.com/vedantmgoyal2009/winget-pkgs-automation/issues/136.
Hello @wingetbot!
Because this pull request has the Validation-Completed label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.
p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.
http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959681048.
Because at http://github.com/vedantmgoyal2009/winget-pkgs-automation/issues/136, the proposition is that it should be using "/lastSuccessfulBuild/", shall that invalidate http://github.com/microsoft/winget-pkgs/pull/33717/commits/40276aa68283b421fcf494cc32d1360d524e05f5#r741972545?
Because at http://github.com/vedantmgoyal2009/winget-pkgs-automation/issues/136, the proposition is that it should be using "/lastSuccessfulBuild/", shall that invalidate http://github.com/microsoft/winget-pkgs/pull/33717/commits/40276aa68283b421fcf494cc32d1360d524e05f5#r741972545?
No.
lastSuccessfulBuild.url from that JSON resolves to https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/1459/ and not https://binary-factory.kde.org/view/Windows%2064-bit/job/Kate_Release_win64/lastSuccessfulBuild/.
I don't see much difference in both other than that one is valid for 24 hours (lastSuccessfulBuild) and the other is valid for a couple of days (build number) plus an edge case between @wingetbot and vedant's automation (i.e. the creation of GitHub issues where the URLs don't work), but ideally lastSuccessfulBuild should not be used. Getting the build number isn't that hard if querying the API. For example: lastSuccessfulBuild.number.
http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959681048.
Because at http://github.com/vedantmgoyal2009/winget-pkgs-automation/issues/136, the proposition is that it should be using "/lastSuccessfulBuild/", shall that invalidate http://github.com/microsoft/winget-pkgs/pull/33717/commits/40276aa68283b421fcf494cc32d1360d524e05f5#r741972545?
Even if it is automated, the lassSuccessfulBuild still should not be used, since there is no way of telling when the automation will or will not work. Static, versioned links are usually preferred since they will generally be more available than dynamic links.
The automation runs on a set schedule. What happens if a build is released right after the automation runs? The link breaks, and its probably at least an hour before the automation runs again, and another hour for the update to be validated and merged in to the repository. Or the automation could go offline, and it could be even longer that the package is unavailable to users.
http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959731646.
Are the nightly builds released inconsistently?
Response
This comment is response to "http://github.com/microsoft/winget-pkgs/pull/33717#pullrequestreview-796879170".
Ideally, KDE should remediate this problem so that automatic replacement is less burdensome for the maintainers of package-managers that are similar to winget, and so that manual replacement shall be less frequent. Consequently, how best might this be remediated: should invalid request for packages that were, but not anymore, within "/lastsuccessfulbuild/" be resolved correctly automatically by "http://jenkins.io" or "http://binary-factory.kde.org"?
This is worth remediating now, so that before more of KDE's software has been added to winget, this problem shall have become non-existent.
This comment is response to "http://github.com/microsoft/winget-pkgs/pull/33717#pullrequestreview-796879170".
Ideally, KDE should remediate this problem so that automatic replacement is less burdensome for the maintainers of package-managers that are similar to winget, and so that manual replacement shall be less frequent. Consequently, how best might this be remediated: should invalid request for packages that were, but not anymore, within "/lastsuccessfulbuild/" be resolved correctly automatically by "http://jenkins.io" or "http://binary-factory.kde.org"?
This is worth remediating now, so that before more of KDE's software has been added to winget, this problem shall have become non-existent.
One way to have the automatic update functionality that you're looking for would be to have a vanity url which always stays the same. That way the URL never needs to be changed, only the version does. What I mean by a vanity url is something like https://binary-factory.kde.org/download/Dolphin_Nightly_win64/latest?type=exe or https://binary-factory.kde.org/download/Dolphin_Nightly_win64/latest?type=appx or https://binary-factory.kde.org/download/Dolphin_Nightly_win64. If the build definitions that KDE uses allowed these URLs to always point to the latest version, because the URL is static wingetbot would be able to update them.
However, this is most definitely something that would need to be changed on KDE's end
This comment is response to "http://github.com/microsoft/winget-pkgs/pull/33717#issuecomment-959828079".
@Trenly, I have reported some of this problemage via "http://bugs.kde.org/show_bug.cgi?id=444894#c0".
Hello @BEEDELLROKEJULIANLOCKHART, The PR could not be validated because there is a merge conflict which adds bad characters to the manifest. Please address the merge conflict and resubmit.
Close with reason: Merge Conflict + Package URLs change daily, and builds are not retained;
Yeah, the currently present manifests are all 404. We'll just have to wait until a solution of provided, I suppose, or use different URLs (if any are available).