On 25/04/16 09:06, John Crispin wrote: > On 25/04/2016 08:54, Bastian Bittorf wrote: >> * John Crispin <j...@phrozen.org> [25.04.2016 07:39]: >>>> The changed image name breaks compatibility for derived projects and >>>> that's something which should only happen if there is a really good >>>> reason (e.g. security fix). >>> >>> how does it beak compatibility ? >> >> I think they auto-download a preconfigured filename, >> which will ofcource not succeed. We circumvented this in our >> network-autoupdater in a way, that we download e.g. "$MODELNAME.bin" >> where $MODELNAME is from '/tmp/sysinfo/model' e.g. 'TP-Link TL-WDR4900 v1' >> and on the downloadserver we can "adjust" the symlinks... >> >> I'am against reverting the commit. Lets keep it, because it makes sense.
It doesn't make sense to change naming conventions within a stable release. For a next stable release, sure fine, go ahead, there it *does* make sense. >> Maybe i can give a short talk at Battlemesh v9 about proper autoupdates, >> because we have ~10 years experience in this (including 500 dead devices >> 8-))) I agree, over the years everyone keeps improving and once in a while that hurts, but auto-updates isn't what we're aiming for. > before i merged the patch i did actually look at the compat issue and > concluded that only docs will be out of date, which is not really > anything new. all issues mentioned are home made ones. specially the one If tomorrow Sasha Levin thinks that the LTS-kernel release of 4.1 should be called 4.1-21 instead of 4.1.21 nothing really breaks. Except a bunch of home made scripts. And some distributions will need to take care of their autobuilds. And a lot of people will spend useless time into figuring out what broke in which way, and they will be angry or sad. An attitude of "Don't break current stable" is a very healthy one. When however you add or change behavior, you save that for a new release. > bastian mentions here. basically fixing your download script and > deploying it in this way will break forward compat as can be seen here. > > we now face the decision of reverting and unbreaking out of tree issues > that can be fixed easily or avoided in future or not revert it and keep > the fix that makes the filenames more consistent. adding the "n" is > after all correct ad the antenna is not "not" detachable on the relevant > models. This sounds like a minor pain. kwadronaut _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel