Skip to content

Commit 92a7caa

Browse files
committed
Add release policy
1 parent 5058419 commit 92a7caa

1 file changed

Lines changed: 29 additions & 0 deletions

File tree

blog/2023-03-14-release-policy.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
---
2+
title: "GraphQL Java release policy"
3+
authors: donna
4+
slug: release-policy
5+
---
6+
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+
9+
## General release schedule
10+
Going forward, we plan to have 4 releases every year, one per quarter. We will alternate between releases containing breaking changes, and releases containing features and bugfixes (without breaking changes).
11+
12+
For example: our next release 20.1 will be in early April 2023, and this will be a feature and bugfix release without breaking changes. Therefore, we’re going to retain Java 8 in the April release. Our subsequent release will be in early July 2023 and will contain breaking changes, including upgrading to Java 11.
13+
14+
## 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.
16+
17+
## 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.
19+
20+
## Deprecations
21+
When code is deprecated, we will wait at least 12 months before removing it (or roughly 4 versions).
22+
23+
## Version numbering
24+
We will continue to use `major.minor` version numbering.
25+
26+
A minor version can include bug fixes and features, but not breaking changes. A major version can include breaking changes.
27+
28+
## Allowing for policy changes
29+
The aim of this release policy to give the community a better indication of release dates, what is contained in releases, and when fixes will be backported. However, we may make a pragmatic decision to diverge from this policy when required. For example, a major and urgent breaking change could result in two breaking change releases in a row. If we diverge from this release policy, we’ll make it clear in the release notes.

0 commit comments

Comments
 (0)