You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to move to a servicing/support model where we only support the latest official MsQuic release, and we're looking for feedback from the community.
Existing Release Model
Every time we create a new official release for MsQuic, we fork a new release/* branch for it. For the support lifetime of that release we would continue to push fixes as necessary. As time goes on, we have more releases, and then more branches to manage. If there is a day one bug that needs to be fixed for every branch, it usually requires at least some extra work to manually merge the fix into each specific branch. Then a new release (patch) must be created with the updated binaries. The expected work involved will only multiply as time goes on.
Proposed New Release Model
Instead of supporting lots of different releases, let's just support the latest release. Clients can continue to use the older releases if they want, but if they need a bug fix, it must be based on the latest release. Let's break this down a bit more:
Effortless Upgrade
This means that a client that uses a particular version of MsQuic will likely be required to upgrade to a more recent version if it needs a servicing fix. We cannot require any changes on the part of the client for this. They must be able to simply drop in the new binary over the old one, and everything "just works".
MsQuic accomplishes this via versioning in our API. The main entry point to the API is versioned, returning a version-specific function table to be used by the client. This allows us to add new features without modifying the behavior of existing code. We have already rev'ed the API several times (we're on 1.8 so far).
Note - This does not require immediate upgrade when there is a new MsQuic release; only if the client needs a fix.
Testing Upgrade
To ensure this behavior we will add additional testing around the upgrade, by running the previous releases' test binaries against the newest MsQuic binary. Any failures will be considered a blocker and must be fixed before the next official release.
Support Cost Reductions
We're a fairly small team of folks that actively work and manage MsQuic, so we'd like to keep the support costs as small as possible. By limiting support to just the latest release we:
DO NOT need to investigate every supported release to see if a bug reproduces there and must be fixed.
DO NOT need to backport fixes to every supported release.
DO NOT need to create new patches for every supported release.
DO have the latest and greatest testing run for every release/patch we do make.
DO encourage the community to generally stay on the latest release.
Ask to the Community
We'd really like to get feedback from the existing folks that use/depend on MsQuic. Is this Ok with everyone? All feedback is welcome!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello Everyone!
TL;DR
We want to move to a servicing/support model where we only support the latest official MsQuic release, and we're looking for feedback from the community.
Existing Release Model
Every time we create a new official release for MsQuic, we fork a new
release/*
branch for it. For the support lifetime of that release we would continue to push fixes as necessary. As time goes on, we have more releases, and then more branches to manage. If there is a day one bug that needs to be fixed for every branch, it usually requires at least some extra work to manually merge the fix into each specific branch. Then a new release (patch) must be created with the updated binaries. The expected work involved will only multiply as time goes on.Proposed New Release Model
Instead of supporting lots of different releases, let's just support the latest release. Clients can continue to use the older releases if they want, but if they need a bug fix, it must be based on the latest release. Let's break this down a bit more:
Effortless Upgrade
This means that a client that uses a particular version of MsQuic will likely be required to upgrade to a more recent version if it needs a servicing fix. We cannot require any changes on the part of the client for this. They must be able to simply drop in the new binary over the old one, and everything "just works".
MsQuic accomplishes this via versioning in our API. The main entry point to the API is versioned, returning a version-specific function table to be used by the client. This allows us to add new features without modifying the behavior of existing code. We have already rev'ed the API several times (we're on 1.8 so far).
Note - This does not require immediate upgrade when there is a new MsQuic release; only if the client needs a fix.
Testing Upgrade
To ensure this behavior we will add additional testing around the upgrade, by running the previous releases' test binaries against the newest MsQuic binary. Any failures will be considered a blocker and must be fixed before the next official release.
Support Cost Reductions
We're a fairly small team of folks that actively work and manage MsQuic, so we'd like to keep the support costs as small as possible. By limiting support to just the latest release we:
Ask to the Community
We'd really like to get feedback from the existing folks that use/depend on MsQuic. Is this Ok with everyone? All feedback is welcome!
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions