*Ducks for Cover*
Wow. I was not expecting the level of discussion (hatred?) I have seen about the new LUFA APIs. Working on LUFA has given me much insight to the workings of real-world projects — it’s forced me to learn better source revision techniques, and the ins-and-outs of managing a project used by many different people worldwide.
One thing I’ve taken from the recent abuse correspondance about the library is that users hate change. Specifically, users hate things changing between versions. Having stood back, I fully agree; the LUFA codebase has changed way too much between versions, since I’ve been subscribing to a programming methodology best suited to a private project (make changes for performance/efficiency always, even if it breaks APIs). This is a poor stance for a library which is meant to be used by others, so that will stop in the next release.
Let me reiterate; with the next LUFA release, I will endevour to keep all the APIs the same, unless there is a pressing need for a breaking change. One such change came recently when I was informed that the endpoint/pipe clearing APIs weren’t suited to the edge-case of received empty packets from the host, which caused me to have to completely alter them to suit. Other changes have been made recently for the sake of simplicity and consistency, much to the consternation of users.
So, here’s the deal – take it or leave it. The next LUFA version will carry big changes, for the sake of simplifying things. This will require more changes in user code, as has been the case previously. However, upgrades beyond the next release should be a painless drop-in replacement affair, unless clearly documented. All the demos will use the new class driver layers I’m working on, to simplify them and reduce the amount of support required for the library, the cruddy not-quite-a-scheduler scheduler will be removed (although users can copy it from an old version into their project if they wish) and the event system/library named callbacks have changed and will require minor user tweaking. Once that’s done, we can all look forward to painless updates and I can look forward to a lot less negative discussion about LUFA.
One more thing that bears reiteration to make certain it’s clear; the new class drivers are a layer on top of the low level APIs for convenience; they do not replace the low level APIs. If users wish to retain their low level code (which is neccesary if they are implementing classes not covered in the library) they can do so.
