We spent the last two years working on major changes on our NETMF SDK, from completely changing the TCP/IP stack to reorganizing the GHI extensions. With the urgent needs of our customers, we had no choice but to make multiple public releases skipping over beta and private releases. This will not be the case moving forward. Here is how we are going to make things easier.
Less frequent releases
Starting with the new year 2015, we will be providing very few public releases, maybe just one. Any updates and fixes will go into a separate optional beta release. We will have as many beta releases as necessary. We will detail what changed in every beta release to make it easy to determine if anyone would need to update or wait for the next official non-beta release. An important note here is that all beta releases will be available only until the next full release is available.
Locking the GHI extension API
The library API is guaranteed not to change for the entire year. Also, any changes in the future will be as backward compatible as possible. Our goal is to make it as easy as possible for you to move to the next release, with no or minor changes on your code.
Old confusing information
There are months old forum posts that talk about the APIs that changed, same goes for codeshare and documentation. We solved the documentation by removing all the old documentation and only showing the new and locked API documentation. Please note that the library references for old SDKs will always be available inside the SDK itself. As for the forum, we will move all old NETMF topics into a separate archive. Finally, codeshare will show a note on any older contributions indicating the new API. We will continue to make our website and offerings easy for new users but also provide support for experienced users.
And the voting begins…
As we begin our new SDK release cycle in 2015 it is important that the community tell us what they think is important. Please visit Task Tracker, http://www.ghielectronics.com/tracker/list/open , and vote on the issues that you would like to see addressed first.
A special thanks to our community and to the loyal customers who helped in making all this happen.
Does that mean that for every forum post, every document, every task, every developer resource, every manual, and every codeshare entry,(etc) there will a question to fill in, asking for specific firmware, and SDK release?
As of right now it’s not synchronized with anything specific. However, if Microsoft released a “new” NETMF release with major changes like networking, a beta GHI NETMF SDK would become a priority. Of course the amount of time to release the beta would vary based on how major the changes are in the NETMF core.
The important thing from all this is having a one very stable release for everyone to use, especially new users and products in production. The documentation will be all around this one release. We want to bring the FEZ back to new users.
And still provide the latest and greatest quickly, even nightly builds if it makes sense. But this will be optional and probably recommended for experienced users only.
I’m not really sure how this will be different. To me more updates is always better than fewer but as long as you are going to release regular updates and just call them “beta” then I’m fine with that. My only real suggestion is that instead of calling them “public” vs “beta” releases that you call them “stable” vs. “beta” releases. I’m assuming the “beta” releases are also public.
“Release early. Release often. And listen to your customers.”
Commercial customers need a stable target, while hobbyists want the latest and greatest. It’s a hard problem to solve, definitely.
Releasing nightly builds is a step in the right direction, I would say. Also, to come at it from the broken record angle, releasing libraries via NuGet (NuGet supports marking packages as prelelease) would make life much easier on your customers).
May I also suggest semantic versioning (http://semver.org )? It gives customers both commercial and non-commercial a reliable way to know when an update is safe to take and when it is not.
There’s no “kinda” or “mostly” semantic versioning. If your old stuff won’t compile, and you didn’t bump the major version number, you’re not doing semantic versioning. To quote the semver spec:
No, was always there but never talked about it. There is a number that increments with library changes and other changes when we fix bugs with no changes to the libraries. However, there were many changes in the past that the library changes almost every time, which is why the numbers didn’t seen like they mean anything.
4.2.11.2
Netmf version 4.2 with GHI library version 11 with version 2 firmware bug fixes. When the library changes, then the firmware update version get reset to zero.
Yea. We have the same problem at my company where we have a “core” framework that all customer apps are built upon. We used to try and keep some reference to the core version within the version number unique to the app but at some point it all gets confusing and really meaningless to try and enforce. There are better ways to track which core version the app version is dependent upon.
@ Gus - I don’t see how that scheme follows the rules outlined on the page Godefroi posted. There’s obviously a method to the madness but its a different set of rules than he proposed.
