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
Thanks for all these good ideas. A summary of my thoughts:
- Use of JSON. Not really risky - there'll be JSON parsers for the foreseeable
future. And sticking in a version field makes it possible to evolve. My primary
concern is that we use a SINGLE straightforward format and create tooling
Hello,
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.
How would it deal with devices that cannot be upgrades (like the past case
of
Hi,
A first step could be to establish a *versions.json* file at the root of
downloads.openwrt.org! The file would allow to check if a device still runs
the latest release. JSON seems common enough and is well supported by LuCIs
JavaScript implementation and also via jshn.sh on a CLI/script
>> A first step could be to establish a *versions.json* file at the root of
>> downloads.openwrt.org! The file would allow to check if a device still runs
>> the latest release. JSON seems common enough and is well supported by LuCIs
>> JavaScript implementation and also via jshn.sh on a
Paul Spooren [2020-02-23 00:04:59]:
[ adding openwrt-devel to the Cc: loop ]
Hi,
> A first step could be to establish a *versions.json* file at the root of
> downloads.openwrt.org! The file would allow to check if a device still runs
> the latest release. JSON seems common enough and is well
