The future plan for GHI's NETMF SDK 2015

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, , 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.

The GHI Electronics Team


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.

1 Like

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.

+1 for moving towards public nightly dev builds.

@ ianlee74 - as you are one one of the experts here, this will not be any different in your case. You will probably always use the latest SDK.

However, this will make a difference to a school teacher who need to lock his class a specific version. You teach classes yourself I think.

Also, commercial customers should stick to those very few releases, especially the ones that have to go through some special expensive licensing.

Note how discussions about any beta releases will be in the beta forum only. This will help in separating thing when doing a forum search.

@ andre.m - correct and when this happens it is up to the customer to decide.

@ Gus - to @ andre.m’s point, could a customer on a stable release (commercial or otherwise) expect hot fixes for critical issues that might arise?

Hot fixes should of course only address defect and not new functionality etc.

May I get a clarification here? Will it be completely locked, or will backwards-compatible changes still be allowed?

@ Simon from Vilnius - we are shooting for no changes but of a change was absolutely necessary then backward compatible.

Depending on the issue and the commercial need, but yes.

1 Like

“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 ( )? 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.

@ godefroi - versioning is already done like that.

Not really. According to that definition, 4.2 should have been 5.0 since it broke existing APIs in a non backwards compatible way.

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:

(emphasis mine)

i think @ Gus is talking about from now and onwards :wink:

I think it’s hard to keep some logic in the major/minor version number (semantic versioning), and stay in sync with the NETMF version number.

Definitely. Probably time to separate the two.

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.

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.

And updating the core framework rests all to zero


1 Like

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.