Enabling The New Release Process
The time has finally come to move on from our current way of releasing the Polkadot SDK. Release 1.14 will be the last of its kind. From then on, we move to the 
New Release Process.
This will deliver more stability and ease of use for parachain developers.
There will be a stable release every three months and bug/security fixes during its lifetime. The idea is that parachain teams can just use cargo upgrade during these three months to stay up-to-date with the latest fixes without having to integrate any changes.
Implications for Parachain Developers
Future adjustments to this process rely largely on your feedback. We want to make the lives of parachain developers easy. If the first iteration does not achieve this, then we ought to change it.
Please report any SemVer violation of stable releases during its lifetime so that we can backtrack and improve the process.
Implications for SDK Developers
Developers need to be aware of this shift in mentality when designing new things. Polkadot is already a platform with tons of good features; we now need to focus on making them more reliable, easy to use and stable. Stable in this sense means to not change something that Parachain Teams are already using.
More concretely, the PrDoc system will be extensively used. The bump of each crate will determine the next version of a crate upon release date. The R0-silent label needs to be used with more care, as to not accidentally break downstream projects.
Getting an API right the first time is difficult. One thing that can help here is to introduce new features as “experimental”. This allows for future changes to the API until it’s properly stabilized, since experimental code can change at any time.
Please refer to RELEASE.md for info on how to merge bug fixes into a stable release.
Implications for SDK Auditors
The tedious task of arguing about audit priorities with stakeholders should be mostly rectified. The order in which audits must happen is exactly the order in which changes got merged into master. One exception exists for backports; as these are critical fixes, they need to be audited out-of-order to be released swiftly.
The head of auditing is responsible for advancing the audited label in lockstep with delivered audits. This label must always point to a commit on the master branch and thereby indicate the latest change that was completely audited. See AUDIT.md.
Implications for SDK Project Managers
New features can only be shipped every three months. This should be taken into account when drafting project timelines.