After reading about the big update, I decided to see if the current Model01-Firmware.ino file is any different. And … it is, but I’m not sure if it’s worth the (admittedly not huge) effort of updating. I’m 99% sure I’m already running 1.23, just with older, possibly deprecated stuff.
The differences I noticed:
New .ino adds host power management
Numlock -> NumPad plugin
Numpad layer is placed before function layer
Kaleidoscope.use() is ditched in favor of KALEIDOSCOPE_INIT_PLUGINS()
The main one I’m curious about is #4, since #1 is obvious, and I don’t use the numpad feature (though maybe I should …).
There are a few other changes worthy of note, such as a big speedup of the main loop, much improved resource usage, and so on. But if you don’t care about that, there’s still a recent improvement that allows the keyboard to work in BIOSes, with OSX’s FileVault, etc. Or, at least, the foundations are there… the pull request that adds support for switching between boot and NKRO mode with Left Fn + Shift + Esc may not be merged yet (I don’t have GitHub open atm, ad am on the go, so can’t check).
The primary reason I’d recommend updating is that it is likely easier now than later, when more changes accumulate. Upgrading in smaller steps is, in my experience, easier than doing so in one feel swoop.
We currently do not announce them, because things are still moving fast. I hope we’ll be able to provide an announcement thread later down the road. But it would be… very high traffic right now.
Great, although I must admit, I’m currently unable to upgrade - probably due to missing a step somewhere. There seems to be a lot of moving parts - very little of which I am familiar with or understand at all.
I even tried nuking everything and re-cloning and whilst I could run make I got a bunch of deprecation warnings (despite everything being freshly cloned) and it didn’t ask me to hit the prog button. It just ended with:
The deprecation warnings are normal, because the compatibility layer is compiled in by default. For flashing, try using make flash. make's default target is the build target now, to avoid accidental flashes when one only wanted to build.
Every time during plugin and/or firmware development. Arguably that’s not the easiest or best target for the end user… I probably would support changing the default to flash once things stop moving so rapidly. (That is, close to a 2.0 release)
I almost always run make flash, because I got in the habit back when running make didn’t give the nice summary of RAM & PROGMEM sizes. It’s easy enough to interrupt the process and just skip the actual flashing, and because it builds everything anew every time, it’s annoying to run make and then have to re-do the same build in order to flash the firmware.