Hi,
Thinking on which info the client side would need, I would remove the
minors info if we can just skip to latest.
Yes, if we always skip to the latest anyway the "latest" key could
contain that version and the rest is simply interpolated. When wanting
to cover release candidates we could use Petrs "candidate" tag, which is
empty if no "prerelease" is available.
And, It's missing a changelog link. Also, each release can have its
own info.json with more info.
I would not store a change log link in a versions.json file but an
additional info.json might makes sense.
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?
The client implementation could make an additional check like reading
<server>/<version>/<target>/profiles.json and see if the profile is
still supported in the new version. If not, it could point to openwrt.org.
If you permanently want to ignore new upgrades, disable the upgrade check.
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?
I'd say target changes are too risky to automate.
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.
I'm against this fragmented rollout based on some random value. Either
the user makes a conscious decision to install freshly released firmware
or not.
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.
Yes, long term we could try to create a community of device testers
where whoever owns the device can perform a list of tests and set a
"stable" bit in some "to be designed" file.
Best,
Paul
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
