<div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">Thinking on which info the client side would need, I would remove the minors info if we can just skip to latest. And, It's missing a changelog link. Also, each release can have its own info.json with more info.</div><div dir="auto"><br></div><div dir="auto">How would it deal with devices that cannot be upgrades (like the past case of 4/32)? Or will it bother the user forever with a nonsense upgrade suggestion? How would it deal with devices target or subtarget changes (like ar71xx -> ath79, or generic -> tiny) or this is more a "go to OpenWrt.org" instead of "click here to download"? And aborted releases that brick devices until a new release is ready, specially when they are specific to a device?</div><div dir="auto"><br></div><div dir="auto">The version.json would speed up upgrade rollout. It would also increase the impact of a bugged upgrade. I would be nice to have something like a staged release process, even just for suggesting them to the user. We could create some form of machine id mixing device mac, urandom seed, board id and the new release version and use it for selecting a device for a stage. It could be a client-side-code only strategy but versions.json could inform the proportion of each stage.</div><div dir="auto"><br></div><div dir="auto">It would also be interesting to have some form of automatic or manual success feedback like "Notify OpenWrt if your upgrade worked". This way, a backend could be notified before the upgrade and expect a response afterwards.</div><div dir="auto"><br></div><div dir="auto">Regards,</div></div>