# Stabilizing Polkadot **URL:** \ **Category:** Ecosystem\ **Created:** [April 2, 2024, 11:14am UTC](https://forum.polkadot.network/t/stabilizing-polkadot/7175 "2024-04-02T11:14:43Z")\ **Posts on this page:** 1\ **Showing post:** 26
**Author:** ![OliverTY](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/oliverty/32/2986_2.png) [@OliverTY](https://forum.polkadot.network/u/OliverTY)\ **Post date:** [June 27, 2024, 11:41am UTC](https://forum.polkadot.network/t/stabilizing-polkadot/7175/26 "2024-06-27T11:41:03Z")
# 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. ![Untitled (1)](https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/b/be65119016d1b84d4184a6d0380afe4dbc4cb2e2.jpeg) ## 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](https://github.com/paritytech/polkadot-sdk/blob/7c6ab07193e60a06de14f90fd3f618ac72ff17b6/docs/RELEASE.md#bug-and-security-fix) 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](https://github.com/paritytech/polkadot-sdk/blob/739c37bfd6df30fac0ffb9b491ee2495e1753054/docs/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. --- _[View the full topic](https://forum.polkadot.network/t/stabilizing-polkadot/7175)._