| Verdict | What it means |
|---|---|
| recommended | Start here. The book's default answer for this job. |
| viable | A defensible choice for a stated reason — a constraint, a data type, or something downstream that expects it. |
| legacy | It works, and you will meet it in existing pipelines. Do not anchor a new one on it. |
| avoid | Actively discouraged. The rationale says what to use instead. |
Preface
Most of what is written down about bioinformatics tools is either a decade stale or a single project’s own documentation arguing for itself. The gap between those is where this book sits: a concepts layer written to be true in ten years, and an implementation layer that says what to run now and admits when it last checked.
That second promise is the hard one, and it is the reason this preface exists. An implementation chapter is not prose about tools; it is a rendering of a machine-readable registry, and every tool on it carries a verdict, a status, a date and a set of language chips. None of that is worth anything unless you know exactly what each one claims. This page is that contract.
Two judgments, deliberately separate
Every tool record carries two fields that readers routinely collapse into one. They answer different questions, and keeping them apart is most of what makes the survey useful.
The verdict is the book’s advice. It is editorial, it is ours, and you may disagree with it.
A verdict never appears without a reason. That is enforced by the registry’s schema rather than by editorial discipline: a record marked recommended with no rationale will not validate, and the book will not build. If you think a verdict is wrong, the rationale beside it is the thing to argue with.
The upstream status is a fact about the project, not about the advice.
| Status | What it means |
|---|---|
| active | Cutting releases. |
| maintained | Fixes land on the default branch, but releases have stopped or slowed. Usable; the fix you need may not be in a tagged version. |
| dormant | No release in about two years and no sign of ongoing work. Not the same as broken — some problems are finished — but check before building something new on it. |
| superseded | A successor exists and the record names it. Start there. |
| deprecated | The authors have stopped, usually by archiving the repository. Nothing will be fixed. |
The two are independent, and the interesting combinations are the ones that look contradictory. A dormant tool can be recommended — some problems are finished, and a program that solved one in 2019 has no reason to release in 2026. An active tool can be legacy — a busy project can still be the wrong place to start. What you should never find here is a status that quietly smuggles in a recommendation, or a recommendation resting on a status nobody checked.
The date beside the status
A status word is a claim. Dormant asserts that nothing has shipped in about two years; active asserts that something has. On its own you would have to take our word for it, so the date of the most recent upstream release is printed next to the word:
NoteReading it
A record marked dormant with last release 2022-02 beside it says: no release since February 2022, and this book classifies that as dormant. You can check the first half against upstream in ten seconds, and you can disagree with the second half without having to doubt the first.
The date is populated by a script that reads the project’s own release feed — GitHub releases for most tools, and PyPI, crates.io, Bioconductor, GitLab or the Julia registry for the rest. It is never typed in by hand, which means it cannot drift away from the version number printed alongside it.
A few entries show a status with no date. That is not an omission: Bioconductor pins a package’s version to its own twice-yearly platform release rather than to the package’s history, and the Julia registry records versions without dates. Where a release date does not exist, none is invented, and the record’s caveat carries what could be established instead.
WarningTwo different dates, and they are easy to confuse
last release is upstream’s date: when the project published the version shown. reviewed is ours: when a human last checked that record — its license, its status, its rationale, the claim in its caveat. Each implementation chapter’s header carries the most recent review date across the page.
A tool can be freshly released and stale in this book, or reviewed last month and untouched upstream since 2019. Both dates are shown because neither implies the other.
How a status is decided
A refresh script queries every project’s release feed and repository, updates the versions and dates, and then proposes status changes. It proposes only where the evidence is unambiguous — an archived repository, or a release older than the dormancy threshold. It never writes a status.
The reason is that the line between active and maintained is not a measurement. It is a judgment about whether a project is being developed or merely kept alive, and no release-date heuristic can make it. A script that guessed would be wrong often enough to teach readers to ignore the field, which would cost more than the field is worth. So the machine finds the candidates and a human decides.
The language chips
Each tool carries chips for the languages it touches. A solid chip is the language the tool is written in. An accented chip is a language you can drive it from through a binding, with the package name on hover. A language the tool does not support has no chip at all.
That last rule is deliberate, and it is the one place where the chips under-promise. They could only ever mark the four languages this book follows — Python, R, Julia, Rust — so a struck-through chip would assert an absence that had never been checked, silent about Java, Go and C++. And for a tool that is a command or a server rather than a library, “no R binding” is a category error rather than a gap.
The gaps are real and they matter: a great deal of bioinformatics is C and C++ behind Python wrappers, R coverage is uneven and concentrated in Bioconductor, and Rust and Julia are strong in some corners and absent in others. That claim is made at the end of every implementation chapter, in prose, where it can be stated precisely and given its reasons. The chips say what a tool supports; the chapter says what the field lacks.
What is not surveyed
The registry covers computational biology and bioinformatics tools. It does not cover general developer infrastructure — package managers, virtual environments, container runtimes, editors, build systems — however much you need one to do the work.
Partly that is scope: a ranking of Python package managers would carry this book’s review date into an argument it has no standing to settle. Mostly it is honesty about the currency promise. Every record here says reviewed year-and-month and means it, and that is only sustainable in a field whose movements the authors would notice. Outside it, entries go stale silently, and stale advice delivered confidently is worse than none.
Where a rung of infrastructure genuinely matters, the concepts chapter carries it and the implementation chapter says plainly that it is out of scope. An absence you can see explained is worth more than a survey that will rot.