1. It's stable enough for feature-parity with the 2.0.x firmware series (i.e. for "big bridge across all ports" operation). Lots more stuff to be added for LACP/VLAN and that standalone-mode bug still needs to be addressed. Nothing that ought to delay a 2.1.0 release imo since there are no regressions. 2. 2.1.0 is smart about reading the EEPROM and selecting the correct hardware configuration for the board. No problems there. The same image can be flashed onto a 2.4 or 2.5.2 board and the user needn't know the difference. 3. That I'm unsure about. Parsing the file and auto-applying the change shouldn't be too hard (I outlined a sketch for what that script would look like here last month), but that complicates downgrading back to 2.0.x if a user decides to try that for any reason; plus, users seem skeptical about such a script's reliability. Changing the path gets us the best of all worlds: downgrading to 2.0.x reverts back to the previous configuration (as long as the user didn't delete it, or it just goes back to default), upgrading 2.0.x->2.1.x won't completely break the network (ditto, it just goes back to default), the user can prepare the new config file ahead of the upgrade if they want, etc.