[OpenWrt-Devel] [RFC] device compat version

Paweł Dembicki paweldembicki at gmail.com
Thu Jun 4 04:31:14 EDT 2020

On 04.062020 at 09:58 Adrian Schmutzler <mail at adrianschmutzler.de> wrote:
> Hi,

Hi Adrian,

> we regularly encounter the situation that devices are subject to changes
> that will make them incompatible to previous versions.
> Removing SUPPORTED_DEVICES will not really be helpful in most of these
> cases, as this only helps after a rename.

I think about it when kirkwood was migrated to DSA[1] and when was
possibility, to broke sysupgrade  images in EA3500 and EA4500 [2].

> An easy way to address this would be the introduction of a
> DEVICE_COMPAT_VERSION to the build parameters of a device (and to
> This could be put into image.mk with a default value of 1, and therefore
> would be applied to all devices in the tree automatically. It could then be
> inserted into the image metadata, and effectively lead to a similar
> comparison (and message) like done for SUPPORTED_DEVICES now.

IMO it should have three stages:
1. unconditional sysupgrade
2. sysupgrade -n required
3. no sysupgrade possible

Some devices need only new config like switching to DSA [1].
Another need back to stock and reflash with factory [2][3].

> If an incompatible change without migration was introduced (i.e.
> swconfig->DSA, sector size chance, whatever ...), one could just bump the
> DEVICE_COMPAT_VERSION in image/Makefile to the next integer only for the
> affected devices.
> All older images without a defined compat_version would just be assumed to
> be "1" or "0".

I suggest use X.Y notation. Default will be 1.0.
When Y was changed, only sysupgrade -n is possible. When X was
changed, only sysupgrade -F should be possible.

> This should provide an easy option to indicate an incompatible change to the
> user, without having to bloat configuration too much, as most devices will
> just stick to the default forever.
> Since I'm not an expert of the sysupgrade mechanics, though, I'd be happy
> about pointers on whether/how that could be implemented.
> Best
> Adrian

[1] https://github.com/openwrt/openwrt/commit/4fd7e539e4f90128bdd7cb71c729a4b32f5de86e
[2] https://github.com/openwrt/openwrt/pull/2977
[3] https://github.com/openwrt/openwrt/commit/1680ae7eae2602dd85463a71f88d0012b236bff7#diff-896e162a6bfaabcbd8f0214d7894109c

Best regards,
Pawel Dembicki

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list