Skip to main content

· 2 min read
Andreas Marek

GraphQL Java has become a mature and widely adopted library over the past 9.5 years. And while we continue to maintain, improve and add features, we don't expect revolutionary changes to the core of the library.

As side effect of this maturity it became clear over the least years, that performance is a key aspect that users are interested in. Especially in larger scale applications performance can have a huge impact on operational costs and user experience.

In GraphQL Java we leverage JMH aka Java Microbenchmark Harness to measure and compare different performance aspects.

Historically, performance testing was done manually by running JMH benchmarks on a local machine.

This comes with the obvious flaw that it's not reproducible over time and across different machines. A benchmark run on one developer's machine is not comparable to a run on another developer's machine (or often even the same machine months later).

We are very happy to share that we have now an automated performance testing setup in place to overcome these limitations by running the benchmarks in an isolated cloud environment.

Currently, it runs on every commit to the master branch and the results are stored in the
performance results folder. You can visualize and compare results with the JMH Visualizer tool, a free tool which runs in the browser. Our goal is to provide clear and reproducible performance improvements over time while preventing any regressions.

This work is sponsored and made possible by Atlassian and we are very grateful for their support.

· One min read
Donna Zhou

We are thrilled to announce the release of graphql-java v22.0! Thanks to everyone in the community who contributed to the release, whether that was code, helping to report issues, or participating in discussions.

This is a breaking change release, which includes major performance improvements. This release also introduces the @defer directive, which enables data to be received incrementally, rather than waiting until all data is resolved. This can reduce an application's time-to-interactive. See more on the @defer draft specification on the GraphQL Working Group's GitHub repo.

For the full details, please see the release notes on GitHub.

· One min read
Donna Zhou

We are pleased to announce the release of graphql-java v21.0! Thanks to everyone in the community who contributed to the release, whether that was code, helping to report issues, or participating in discussions.

And a very Happy 8th Birthday to graphql-java, who celebrated their birthday last week!

This is a breaking change release, including upgrading to Java 11 and changes to parseValue coercion. See the full release notes on GitHub.

· 2 min read
Donna Zhou

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.

General release schedule

caution

Since this blog post was published, we changed our release schedule from 4 times to 3 times per year.

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).

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.

Security backports

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.

Bugfix backports

We will backport important bug fixes at most 12 months. These fixes will be backported depending on the severity of the bug and demand.

Deprecations

When code is deprecated, we will wait at least 12 months before removing it.

Version numbering

We will continue to use major.minor version numbering.

A minor version can include bug fixes and features, but not breaking changes. A major version can include breaking changes.

Allowing for policy changes

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.