@jeiden Thanks SO much! This was really helpful, and would be a great addition to the dashboard documentation.
A clarifying question, for purposes of versioning and compatibility, can we assume you guys are using semantic versioning? i.e.
0.4.9 ~ MAJOR.MINOR.PATCH
That is, backwards compatibility can be assumed for anything that doesn’t change the major version number? So, when you go to 0.5.0 soon, it should be back compatible to 0.4.9, but when you guys hit 1.0.0, all bets are off?
@mdma – can you answer @dan’s question on how we will be approaching backwards compatibility when we reach firmware 1.0.0?
We are using semantic versioning. With the 1.0 release we may see some deprecated APIs finally disappear, and some general cleanup of the API space, although in practice I imagine this will happen before 1.0 so that we can reach a stable API before 1.0 is released. We always try to avoid breaking changes, but where these are inevitable then they will be announced at least one release in advance of the breaking change.
This is regarding compiling against the current API. The system firmware will always be backwardly compatible, so you can always safely use a newer version of system firmware with an older application.
We want the upgrade process to be as smooth as possible, so we go to some lengths to avoid breaking changes and maintain compatibility. 
I hope that answers your query - just let me know if I need to cover any points in more detail.
Thanks @mdma That’s helpful confirmation. I guess strictly under semantic versioning the API shouldn’t break until it hits 0.X.X -> 1.X.X but thanks for letting us know this might happen and that we will get at least one release’s notice. We read the release notes very carefully
I’ll be sure to put them under a heading BREAKING CHANGES in flasying nyan :-). Thinking about it, we can prep the breaking changes in the 1.0 api via release candidates, e.g. 1.0-rc.1 etc… so we may not need to add breaking changes to the 0.x line.
@jeiden, my Electron device has firmware version 0.5.2 and the app was also built with firmware version 0.5.2.
I had wanted to compile the app with version 0.5.3 but it keeps telling me that the device is running device firmware version 0.5.2, I want to upgrade over the air, but it keeps warning me that the device the will go into safe mode, but it’s not giving me the option to go ahead.
How can I achieve this using the IDE?
AFAIK pre 0.5.3 there is no way for an OTA firmware upgrade.
So you might need to get physical access to your Electron to get that version flashed, only after that you should be able to flash system OTA in future.
@ScruffR, I’ve been battling to flash it using DFU mode with no success. I installed Zadig, and the error on USB devices has cleared. The electron is blinking yellow, but I keep getting no DFU device found.
Can you provide a screenshot of DevMgr with the device in DFU Mode and a screenshot of zadig with the device selected?
When installing the driver via zadig, the device has to be in DFU Mode too.
Otherwise, if you have serial access, you can also flash in Listening Mode via
particle flash --serial firmware.bin
@Donwhale, do you have the lastest Zadig v2.2? If not, you need to get it. Once you have it, install the WinUSB(7.1.7600.16385) driver and NOT the libusk one since you are running Windows.
@peekay123, I uninstalled the previous one and re-install by choosing WinUSB, the zadig version is 2.2, but i’m getting the same error.
We also saw issues with some USB cables, try some others.
Also trying a USB 2.0 instead of 3.0 might make a difference.
You also need CLI 1.16.0 or higher.
BTW, libusbK works fine for me in Windows.
Is there already a way to System Firmware update OTA for electron via the IDE or an App, or is something planned?
Being new to the platform it has been one of the most difficult things to find info about. I found out I can do particle update in the CLI, but can not seem to find that info again:
particle flash [device id] system-part3-0.6.2-electron.bin
then wait a minute or two to flash part 2 and then wait a minute or two to do part1.
It is a bit fiddly when the device is in the field, so you can not see the LED's. A "one button click" would be more than nice. Like in the IDE for photons if you choose another firmware as target than what is already in the device.
That's possible but currently only for Electrons registered as Products ( Particle Console | Build your connected product )
The USB way is much easier (with the more recent CLIs in DFU Mode)
particle update
that's it.
USB is easy when the device is on the desk, and products looks like a great way to handle it when a stable firmware is ready for the field.
In between them, it will be great to be able to update single device with one click to test different configurations/bugfixing in the field.
I hope Electrons will some day get the samme one-click update option as Photons in the Web IDE.
You can mark a single device (or a collection of them) of a product as development devices for exactly that in-between state.
I still hope Electrons will some day get the samme one-click update option as Photons in the Web IDE.
I have tried Products setup now and it works well. Thanks for “pushing” that option.
I do miss an ability to force an update now when releasing a new firmware. I guess you batch call a reset function on all product devices?
What reset function would cause an immediate update?
This is not a 'one-click' option, but using this page, you should be able to push the firmware parts for 0.6.2. I didn't have a chance to test it yet for the electrons, but at some point, it worked for Photons, and the console showed a 'successful' message. No guarantees though 
I suggest keeping the console open, and only flashing the next part after the console returned a successful flash.
Let me know if it works ;)?