Why you should always update to the latest micro versions!
We often get questions about how the Quarkus maintainers handle multiple branches and how this impacts releases. This short post attempts to provide the necessary information for answering such questions.
Development branch
When a maintainer or contributor wants to make a change to Quarkus source code, a Pull Request is opened against the main branch.
This means that all changes once merged are part of the main branch and there are no feature branches (a practice that is sometimes referred to as trunk based development).
The Maven version used on the main branch is always 999-SNAPSHOT
|
|
For folks who want to contribute to Quarkus but are uncertain which branch their new change should target, the answer is unequivocally the |
New major or minor version
As a short reminder, Quarkus always provides at least one Candidate Release version of a new minor or major version (in the latter case, there are almost always multiple such releases).
These releases use the CR* suffix, so for example the first candidate release for the 3.11 release was 3.11.CR1.
When time comes to do the new Candidate Release version of a new minor version a new branch using the major and minor is created at the head of the main branch.
For example for the 3.11 release, the branch was made of the following HEAD:
After the release process is completed, the branch looks like this:
New micro version
After creating the release branch, all subsequent changes to main will target a future release unless they are backported to the release branch.
As we absolutely want a release branch to include the latest bug fixes from main, a manual triage needs to occur in order to decide
which changes in main should be backported to the release branch. The maintainers of the Quarkus use the triage/backport* labels
on candidate changes.
When time comes to release a new micro version (or the final .0 version), the selected changes are manually backported to the branch
New features from main are not backported to the release branch (with very few exceptions) as we want release branches to be as stable as possible.
|
For example, for the 3.11.0 release the branch looked like this:
Compare this with the image for 3.11.0.CR1 and you’ll see that only safe changes are included.
Same for 3.11.1:
| This backport process happens independently for each supported release branch. It’s also the reason why the GitHub project has multiple backport labels. |
まとめ
If Quarkus users should take away one thing from this post it’s this:
Regardless of the minor version of Quarkus being used, it is important to always use the latest micro version of a release. The reason for doing so should be evident from
this blog post, but it is worth reemphasizing: The latest micro release - let’s call it .z - is almost always going to be more stable than .0 (or anything before .z)
since it only contains bug fixes and does not contain new features, as those have a higher chance of introducing new bugs.
As to which version of Quarkus to use, it comes down to the following question:
Does my project value bleeding edge features or stability?
If the answer is the former, then the absolute latest Quarkus version on Maven Central should be used. If the answer is the latter, then the latest LTS version of Quarkus should be used.
