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
Copy file name to clipboardExpand all lines: blog/2023-03-21-release-policy.md
+8-5Lines changed: 8 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,18 +7,21 @@ slug: release-policy
7
7
We’re formalising our release schedule to give the community a better idea of when to expect releases, what will be contained within them, and when important fixes will be backported.
8
8
9
9
## General release schedule
10
-
Going forward, we plan to have 4 releases every year, approximately one per quarter. We will alternate between releases containing breaking changes, and releases containing features and bugfixes (without breaking changes).
10
+
:::caution
11
+
Since this blog post was published, we changed our release schedule from 4 times to 3 times per year.
12
+
:::
13
+
Going forward, we plan to have 3 releases every year. We will alternate between releases containing breaking changes, and releases containing features and bugfixes (without breaking changes).
11
14
12
-
For example: our next release 20.1 will be in late March 2023, and this will be a feature and bugfix release without breaking changes. Therefore, we’re going to retain Java 8 in the 20.1 release. Our subsequent quarterly release will be around early July 2023 and will contain breaking changes, including upgrading to Java 11.
15
+
For example: our next release 20.1 will be in late March 2023, and this will be a feature and bugfix release without breaking changes. Therefore, we’re going to retain Java 8 in the 20.1 release. Our subsequent release will be around early July 2023 and will contain breaking changes, including upgrading to Java 11.
13
16
14
17
## Security backports
15
-
We will backport critical bugfixes and security fixes for versions dating back 18 months (or roughly 6 versions). These fixes will be backported depending on severity and demand. As security fixes are time sensitive, we will release them on demand instead of waiting for the next quarterly release date.
18
+
We will backport critical bugfixes and security fixes for versions dating back 18 months. These fixes will be backported depending on severity and demand. As security fixes are time sensitive, we will release them on demand instead of waiting for the next release date.
16
19
17
20
## Bugfix backports
18
-
We will backport important bug fixes at most 12 months (or roughly 4 versions). These fixes will be backported depending on the severity of the bug and demand.
21
+
We will backport important bug fixes at most 12 months. These fixes will be backported depending on the severity of the bug and demand.
19
22
20
23
## Deprecations
21
-
When code is deprecated, we will wait at least 12 months before removing it (or roughly 4 versions).
24
+
When code is deprecated, we will wait at least 12 months before removing it.
22
25
23
26
## Version numbering
24
27
We will continue to use `major.minor` version numbering.
0 commit comments