[OpenWrt-Devel] RFC: versions.json

[Rich Brown]

>> 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 level.
> 
> I'm wondering whether this JSON is really needed, wouldn't just some kind of
> unified symlink/directory structure would work as well? I mean, why to care
> about another JSON file content if the same could be achieved otherwise.

It's true that the actual representation (symlink/directory structure, JSON file, a massive text file listing every release, etc) doesn't matter. In some way, they're all "convertible" to the other forms. 

But we are creating an API here. People want to write software against that API, knowing they never will have to tweak their software because a new version or important branch, etc arises.

What matters is that OpenWrt pick ONE FORMAT to be the canonical representation of this information, and that our build system automatically create data IN THAT ONE FORMAT as a matter of course, so that everyone can rely on it for their needs. 

> Do we need to care about archive releases?

Older versions of the firmware (pre-20.xx) won't know how to interpret the API data, so we don't need to cater to those older images. However, in the future when Stable is 23.07.2, and you encounter a 20.07.1 machine, you'd like to it to show you the upgrade options based in its image.

Do the choices below cover the waterfront for a complete set of useful names? (Let's assume that 19.07.2 has been released, and that there are two RCx builds: 19.07.3-rc1 and 20.07.0-rc2...)


> snapshot          -> snapshot
> release/candidate -> 20.07.0-rc2
release/candidate -> 19.07.3-rc1
> release/current   -> 19.07.2
release/previous -> 19.07.1
> release/previous  -> 18.06.7
release/previous -> 18.06.6
...
release/previous -> 18.06.0
release/endoflife -> 17.01.6
...
release/endoflife -> 17.01.0
release/endoflife -> 15.05.
release/endoflife -> 14.07
...
release/endoflife -> 0.9 (all the way back to White Russian...)

>> Update check script should look for the closest version found in the same
>> channel. So a *stable* 19.12.3 device updates to 19.12.5 
> 
> Wouldn't it be safer to upgrade first to 19.12.4? :-)

This is an interesting and important question, but it's orthogonal to the question of an API that represents the variety of builds that are available.

Thanks.

- Rich

>> This could also introduce channels like "stable" (latest point release),
>> "testing" (rcN) and "unstable" (snapshots). As a dict is used the *versions*
>> array could be extended without losing compatibility.
> 
> Déjà vu[1]? :-) 
> 
> 1. http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018646.html
> 
> -- ynezz
> 
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-adm


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel