On 26/04/2016 09:22, kwadronaut wrote: > 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
i fail to extract from your mail what you are trying to tell us _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel