logback 1.6.x: the compatibility table that labels itself 1.5.x

Three drop-in generations, and a table headed 1.5.x

The compatibility story is a chain of promises. The 1.6.x series is a direct descendant of, and a drop-in replacement for, the 1.5.x series, which is itself a direct descendant of, and a drop-in replacement for, the 1.4.x series. Three generations of drop-in claims sit in one paragraph.

The table that follows is captioned as a summary of 1.5.x dependencies, and the only row inside it is for 1.6.x:

|Logback version   |github branch  |SLF4J version  | JDK at runtime | JDK during build | Enterprise Edition (optional)|
|:---------------:|:--------------:|:-------------:|:--------------:|:----------------:|------------------------------|
| 1.6.x           | master         | 2.0.x         | 11             |  17              | Jakarta EE (jakarta.* namespace)|

So the caption and the contents disagree about which line the table describes. It does not change the values, since the single row is unambiguous about the 1.6.x line, but anyone scripting against that section has to know which row they are reading. The last column is the other thing to notice: an optional enterprise edition running on Jakarta EE and the jakarta.* namespace is part of the support matrix, while the rest of the project is plain Java on the two JDKs above.

Build with 17, deploy on 11, and the gap is deliberate

The build requirement and the runtime requirement are not the same number, and the difference is the practical detail for anyone deploying this. The project states that version 1.6.x requires Java 17 to compile and build, and the compatibility row puts JDK 11 in the runtime column. Nothing in that row describes Java 11 as a build JDK.

The consequence is a two-JDK setup for most teams. Your build agents and CI images need 17, because the sources will not compile on anything older, while the JVMs your application runs on can stay on 11 as long as the produced bytecode targets it. If your organisation is still standardising on a single JDK across the pipeline, this line does not fit that policy without a second image, and that is a decision to make before the upgrade rather than after.

The repository root supports the same conclusion from the tooling side: the pom.xml at the root drives a multi-module build, and version.pl sits next to it. Building is a Maven invocation, not a script, and the project keeps its own version in a Perl file rather than only in the build descriptor.

logback-access was moved to its own repository, and the directory is still here

The stated difference between 1.6.x and 1.4.x is the relocation of the logback-access module to its own separate GitHub repository, and the project links that repository directly. That sentence is the compatibility note for people upgrading across three series.

The tree at the root of this repository still contains a logback-access/ directory alongside logback-core/, logback-classic/ and logback-examples/. Whatever remains there is not a contradiction in itself, since a relocation can leave a stub, a submodule pointer, or a redirect behind, but it does mean the statement cannot be checked from the directory listing alone. If you are migrating from 1.4.x and you take the module list from the repository rather than from that paragraph, you will still see an access module and may conclude the artifact is still built here.

The practical check is the build descriptor rather than the directory list: pom.xml at the root is what decides which modules the reactor builds. Anyone upgrading should read that file for the 1.6.x line and confirm whether logback-access is a module, a pointer, or a leftover before planning the dependency change.

Half of the module list is test scaffolding

Read the top level as a build plan rather than as a feature list. The repository carries logback-core/ and logback-classic/, then three directories whose names say what they are for: logback-core-blackbox/, logback-classic-blackbox/ and logback-classic-misc/, plus logback-examples/ and a separate src/ at the root.

Two thirds of the modules are therefore test or sample code, which tells you something about how this project is validated. Blackbox modules sit next to the module they exercise and run against its output rather than its internals, and the misc module collects the cases that do not belong to a single feature. A change to core that alters a serialized format or a configuration file has to satisfy the blackbox module as well as the unit tests, which is why the pull request process asks contributors to make sure their code passes existing unit tests before submitting.

The static analysis configuration sits in the same layer of the tree. findbugs-exclude.xml, codeStyle.xml and javaConventions.xml are all at the root rather than inside a module, so exclusions and conventions are defined once for the whole build instead of per artifact. A contributor adding code inherits those conventions by being in this tree at all, which is the cheapest enforcement mechanism available and the reason those three files are not buried in one module.

The newest release is dated after the last recorded push

The release timeline has a wrinkle worth noticing before you pin a version. The three newest releases are 1.6.5 on 2026-10-02, 1.6.4 on 2026-09-24 and 1.6.3 on 2026-08-14, so the cadence tightened sharply, from roughly six weeks to a little over one week. The repository is not archived, and the last recorded push to the default branch, master, is dated 2026-09-30.

That push date sits two days before the 1.6.5 release date. A tag can be created without a new commit, and the recorded push follows the default branch rather than every branch in the repository, so this is a bookkeeping observation rather than a contradiction. It still has a practical consequence: if you compare the commit you built against the release you depend on, the timestamps will not line up in the order you expect, and the tag name is the only reliable link between the two.

The tag naming has its own convention. The tags are v_1.6.5, v_1.6.4 and v_1.6.3, where a low line character separates the prefix from the dotted version, and each release is titled with the plain form as well. Automated release tooling that assumes v1.6.5 will not match anything here.

Urgent bugs are routed to a sponsorship page, not a mailbox

The project states two rules about how to reach it. For problems of any kind, the instruction is to post on the GitHub discussions forum, and it adds explicitly that you should not e-mail the developers directly. For urgent issues, the documented mechanism is to champion a release through the project's GitHub Sponsors page, with a link to a specific sponsorship tier.

The stated expectation attached to that mechanism is that most championed issues are solved within three business days and followed up by a release. That is the strongest service commitment in the repository, and it is tied to a funding action rather than to severity or impact, which reframes what urgent means here: a report becomes urgent when someone is willing to sponsor the release work.

For everyone else, the default path is the discussions forum and the contribution process. The two are not interchangeable in the project's own framing. Sponsorship is described as a way to get a fix released quickly, while an ordinary issue goes through the same review machinery as any other change, with tests and a signed off commit.

The pull request checklist asks for the same explanation twice

The contribution process is a numbered list of seven steps, and it is specific enough to be worth reading as a contract rather than as advice.

Fork the repository, ideally create a branch from your fork so changes are easy to merge back, and make the effort to explain the aim of the proposed change. Then make the changes on that branch, be sure the code passes the existing unit tests, and add unit tests for the work if appropriate, which the text notes it usually is. Push to the fork branch rather than to master, submit the pull request from the commit page, and explain the proposed changes again in the pull request itself. Steps 2 and 7 ask for the same explanation twice, once as an intention and once as a description, and anyone following the list literally will write it twice.

The hard requirement is the sign off. All commits must carry a Developer Certificate of Origin sign off attesting to the certificate, and commits without one are rejected automatically by a GitHub check application rather than by a human reviewing the diff. That is the step most likely to send a first contribution back, because the rejection happens before anyone reads the code.

The documentation lives on a website, and the license field names nothing

Two things the repository does not contain are worth knowing about.

The first is documentation. The project sends readers to a documentation page on its web site, and building instructions point at a setup page anchored on the IDE section. There is no docs directory in the tree, and no configuration samples in it either, so the questions that actually decide your deployment, such as which appender to configure or how a config file is discovered, are answered somewhere this repository does not carry. The same applies to the project history and the release notes for anything older than the three most recent releases.

The second is a license name. The tree has a LICENSE.txt at its root, while the license recorded in the repository metadata is left unasserted rather than named. Those two do not agree on their face, and nothing in the tree says which text governs the code, so read LICENSE.txt and decide from its contents. A library that sits underneath other people's services is exactly the place where that question should be answered before adoption rather than during a license audit.

One small inconsistency sits alongside both: the recorded home page uses plain http while the documentation links inside the project use https.

Editorial conclusion

logback fits a Java service that already standardises on SLF4J and wants an implementation with a released 1.6.x line behind it, and the compatibility row in this repository is enough to decide the JDK pair you need before you download anything. Two things are worth checking in your own checkout rather than taking from this description. The license metadata recorded for the repository does not name a license while the tree carries a LICENSE.txt at its root, so read that file and decide from its text. And the newest release tag is dated two days after the last recorded push to the default branch, which is the kind of detail that makes you check whether the artifact you depend on matches the commit you think it does.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qos-ch/logback on GitHub
4. README
5. Releases