Open axetroy opened 2 years ago
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
The simplest way to change without BREAKING CHANGE
diff --git a/packages/electron-updater/src/providers/Provider.ts b/packages/electron-updater/src/providers/Provider.ts
index 819c4a21..25369334 100644
--- a/packages/electron-updater/src/providers/Provider.ts
+++ b/packages/electron-updater/src/providers/Provider.ts
@@ -13,6 +13,7 @@ export interface ProviderRuntimeOptions {
platform: ProviderPlatform
executor: ElectronHttpExecutor
+ customChannelName?: (channel: string) => string,
}
export abstract class Provider<T extends UpdateInfo> {
@@ -43,6 +44,7 @@ export abstract class Provider<T extends UpdateInfo> {
}
protected getCustomChannelName(channel: string): string {
+ if (this.runtimeOptions.customChannelName) return this.runtimeOptions.customChannelName(channel)
return `${channel}${this.getChannelFilePrefix()}`
}
updater.setFeedURL({
provider: "generic",
url: "http://example.com/",
channel: "latest",
customChannelName: (channel) => {
return `${channel}_${process.platform}_${process.arch}`;
},
});
Then the channel file will be
latest_darwin_x64.yml
latest_darwin_arm64.yml
latest_win32_x64.yml
latest_win32_ia32.yml
latest_win32_arm64.yml
latest_linux_x64.yml
latest_linux_arm64.yml
Update: Why do I think this design is very bad?
Because these files are always deployed on the server, these operations often are not developers to do it.
They will be confused.
Q: "why are these files so confusing, I can't understand the relationship between them. Can you change to it more readable?"
A: No. These names are fixed and cannot be changed.
I have explained many times
I think there's a wider issue with channels. Until recently, Electron Builder's auto-update would allow Electron apps that have an "Electron channel" in their package.json
version number, e.g. v2.0.8-E
(with E
standing for Electron) to update via a release tagged on GitHub as v2.0.9
(with no -E
). However, recently this has stopped working, and the app blocks such updates, forcing the app to stay only within its channel.
This is poor channel design, as it should be possible (ideally optional) for upgrades from a sub-channel to a non-channel. But the relevant option is unfortunately auto-set by Electron-builder in the case of GitHub at least, and it does not seem possible to override it.
The problem is the hard-coding of what constitutes a channel. Auto-update only recognizes -alpha
and -beta
. I have to agree that this is suboptimal design. Not only are these hard-coded in English, but the app makes automated assumptions about them that fail if the channel names are not as expected.
The name of this is awful idea
https://github.com/electron-userland/electron-builder/blob/28cb86bdcb6dd0b10e75a69ccd34ece6cca1d204/packages/electron-updater/src/providers/Provider.ts?_pjax=%23js-repo-pjax-container%2C%20div%5Bitemtype%3D%22http%3A%2F%2Fschema.org%2FSoftwareSourceCode%22%5D%20main%2C%20%5Bdata-pjax-container%5D#L29-L37
It's really really ugly
The most important is YOU CAN NOT CHANGE IT
Because you can only change the name of the channel, not its suffix
The
checkForUpdates()
is always send request tohttp://example.com/<channel><suffix>.yml
WHY NOT design with this or something like this
even without any suffix, suffix will be desiced by user