Release cadence

[aalmiray]

Hello everyone,

Since the early days JReleaser has had 2 release paths: fast & slow.

The fast path is the early-access release, posted every time a commit is pushed to the main branch. This type of release allows early adopters to test out new features as soon as they are added to the main branch. Consumers of the jreleaser/release-action GitHub Action can take advantage of the version property exposed by said action to select this release. Early Access releases are intended to be downloaded manually as they might be unstable and as such only CLI related artifacts are posted. There are NO early access releases for the Maven and Gradle plugins. However, should you feel like trying them out you can build your own snapshots from source.

The slow path is the stable releases. Before 1.0.0 we used to post released every month, at the end of the month. This gave us the opportunity to accelerate adoption of new features for those projects that prefer stable releases. These releases include artifacts for all consumer channels: CLI, package managers (Homebrew, Scoop, Docker, etc), Maven Central, Maven & Gradle plugins.

With 1.0.0 out the door back in April 10th and 1.1.0 in June 30th, it's time to adopt a release cadence. This will allow developers to plan ahead and be ready when the next stable release drops. For now, the release cadence will be set to 2 MONTHS. This means that 1.2.0 will be scheduled for end of August 2022, 1.3.0 for end of October 2022, effectively posting stables released at the end of the even months of the Gregorian calendar.

It's our hope that the fast & slow release paths will give you the confidence to adopt the tool and decide when to switch to newer versions in accordance to your own circumstances.

The JReleaser team.

[cwensel]

I see no mention of maintenance releases. It would be great if there was a path for fixes to make it into a stable release across all the artifacts.

[aalmiray]

What do you mean by maintenance releases? Is it patch/fix/point releases to the current minor and/or to previous releases other than current minor?

[cwensel]

yeah, sorry, meant patch release.

I only see a main branch, which I assume leads to a minor release which sounds like has a 2 month cadence from above.

I probably missed it, but I don't see a branch that would be suitable to submit PRs against that would result in a patch release against a current stable minor release.

[aalmiray]

Correct. We don’t have a policy in place for patch releases other than fixing critical bugs within the next 2 weeks after a minor release (that was the case for 1.3.1 and 1.5.1). Following semver features require posting minor releases, not patch releases.