The Windows MIDI Services App SDK ships in two pieces
We do not enforce updates, but customers will prompted to update their runtime installation through the MIDI Settings app. Applications also have access to the APIs to prompt the customers in the same way.
The NuGet package is a compile-time artifact.
As a result, the two could get out of sync. For example, a customer could have version 1.2.3 installed, and the app was compiled against 1.0.2. How will this work?
Except for during the preview period before the first production release, the App SDK generally follows SemVer versioning rules. The version is represented by Major.Minor.Patch with some additional build number and preview data optionally at the end.
Here’s what you should expect when looking at version numbers between the NuGet package and the SDK Runtime.
| Version Component Change | Expectation |
|---|---|
| Major | When this number changes, compatibility has been broken. Compatibility is only guaranteed within a single major version number. We’ll install side-by-side with the previous compatibility version to ensure both old and new apps will work. Apps using the new SDK version may have a different bootstrapper COM component to activate. |
| Minor | New features have been added which typically only light up for apps using a matching NuGet package. Older apps will continue to work as expected. If compatibility is broken, that is a bug. |
| Patch | Bug fixes. No SDK compatibility changes, but could have limited behavioral changes as a result of the bug fix. |
| Build metadata | Internal. Not factored into compatibility. Resets with each patch. |
The MIDI Service itself may require changes over time, and is delivered with Windows. Our plan is to not break compatibility here, but instead to add on to existing interfaces or create new interfaces as-needed, just like we do for other COM APIs in Windows. We also have a good extensibility mechanism based on json which makes the creation of new COM interfaces needed only in limited circumstances. For example, adding a new type of Transport does not require a new interface, because we handle transport configurations through a common JSON endpoint.
Windows MIDI Services is an open source project with all source available on GitHub. We have a great community on Discord as well. Between GitHub and Discord, you should find the information you are looking for.
