Retrofit under lysine.dev: a 194-word README and Square's group id

Four download lines, one ProGuard note, one license

Retrofit, the type-safe HTTP client for Android and the JVM kept under lysine.dev, has a README that fits on one screen. It names the project, sends you to https://lysine.dev/retrofit/ for anything further, gives a download, states a version floor, explains the R8 and ProGuard situation, and pastes the Apache 2.0 text. That is the entire file, and it runs to 194 words.

Nothing in it shows a declared interface, an annotation, a converter, or a single call. It does not show how a response type gets bound to a URL, and it names none of the converters that exist in this repository. The consequence is concrete: if you are picking an HTTP client by reading its documentation, this one defers the decision to a page you have to load somewhere else, and leaves you with no basis for judging the surface you would be maintaining until you do.

The coordinates still read com.squareup.retrofit2

This build publishes under Square's original group and package names. The download line names the coordinates `com.squareup.retrofit2:retrofit:3.0.0`, the code inside the JAR sits in the retrofit2 namespace, which is why the shipped rule file is called retrofit2.pro, and the license header still reads Copyright 2013 Square, Inc.

The practical consequence is that the coordinates are not a way to identify this project. If more than one repository sits on your dependency resolution path, nothing in the coordinate tells you which one answered. A lockfile entry reading `com.squareup.retrofit2:retrofit:3.0.0` is consistent with more than one published artifact, so any supply chain check that reads only group and artifact names will not distinguish the lysine.dev build from anything else under that name. Recording the repository you resolved from is left entirely to you.

The ProGuard link points at a branch named master, not trunk

The shrinking rules ship inside the library as a resource file, and R8 picks them up on its own. ProGuard does not, so you are told to add the options from retrofit2.pro by hand. The link given for that file is written against a `master` path: `https://github.com/lysine-dev/retrofit/blob/master/retrofit/src/main/resources/META-INF/proguard/retrofit2.pro`. The repository's default branch is `trunk`.

So the path the file points you at is not a path in the branch you are reading. If the link resolves, you are copying rules from whatever sits at that path right now rather than from the rules matching the version in your build. If it does not resolve, you are left guessing at the keep rules. Either way the text here does not tie those rules to a released version, and confirming that they match what you resolved is your problem to solve.

OkHttp gets a sentence in the prose, okio gets only a link

The R8 section closes by saying you might also need rules for OkHttp, which it names as a dependency of this library. Two targets sit in the link block: `https://lysine.dev/okhttp/r8_proguard/` for OkHttp and `https://lysine.dev/okio/#r8-proguard` for okio. Only the first is attached to any claim in the prose. The okio entry exists in the file, but nothing tells you when you would need it or how the two rule sets relate.

If your build pulls okio in, you get no test for whether that is your situation and no ordering between the rule files. When keep rules are missing, what you get is a failure on a code path that only runs in a shrunk release build, so the first sign of it often arrives after you have shipped. Guessing wrong in either direction costs you, and this file does not narrow the guess.

A commit from 2026-09-29, a release from 2025-05-15

The most recent commit landed on 2026-09-29, so the branch is being worked on right now. The newest published release is much older than that. Releases 3.0.0 and 2.12.0 both carry the date 2025-05-15, and before them 2.11.0 sits at 2024-03-28. That leaves about sixteen months between the last release and the last push.

The gap has a practical meaning. Take the version a build resolves by default and you are on code from May 2025 while trunk is a day old, with nothing here describing what the newer commits changed. The development line is published separately as snapshots in Sonatype's `snapshots` repository at `https://s01.oss.sonatype.org/content/repositories/snapshots/`, so your choice is between unreleased code and no information about the unreleased code. The file does not tell you what you gain by moving.

Eight Gradle modules, one documented coordinate

The repository is a multi-module Gradle build. Its top level holds `retrofit/`, `retrofit-adapters/`, `retrofit-bom/`, `retrofit-converters/`, `retrofit-mock/`, `retrofit-response-type-keeper/`, `samples/` and `website/`, next to gradlew, gradlew.bat, settings.gradle, build.gradle and gradle.properties. Example code lives under `samples/build.gradle` and `samples/src/`.

The single set of coordinates given covers only the core artifact. Nothing here says which coordinate to use for the BOM, which one the converters publish under, or what version to put on the adapters so the parts line up. `retrofit-bom` exists precisely to make that alignment mechanical, and the file never mentions it. The structure that would spare you from mismatched module versions is present in the directory listing and absent from the documentation, so you end up reading build files to work out the coordinates yourself.

The name is overloaded well past software

Retrofit is an ordinary English word, and the string points at far more than this library. Competing senses of the same spelling include fitting new windows into an existing frame, installing recessed lighting, fitting a smart lock, the verb together with its synonyms, the meaning in electrical work and in construction, questions about which materials such work involves, clothing sold under the name, a company in Singapore and another in Tampines, and the pronunciation of the word itself.

The software side of the same spelling asks how to use retrofit in android, in android kotlin, in android studio, in android java, in jetpack compose, in kotlin, in flutter, and retrofit bolt. The file answers none of them. The consequence for anyone working on this dependency is that a bare name lookup turns up window frames and clothing alongside source code, so licence checks, audits and vulnerability lookups driven by the name alone need to be qualified by the group id before they mean anything.

A version floor with nothing underneath it

The stated requirement is Java 8+ or Android API 21+. The file does not say what a lower runtime does, whether the floor applies to the JDK you build with or the device you run on, or what changed at that boundary. API 21 is a hard number a build tool can enforce, but the mechanism is not described, and nothing covers what you hit if you compile against a newer language level than the one named.

That single line is also the only compatibility statement here. There is no list of supported OkHttp versions, no note about which converter modules exist for which formats, and no mention of the Kotlin or Compose usage that the questions attached to the name ask after. The floor gives you a boundary to check against and nothing beyond it, so verifying that your build and your devices actually clear it is the first thing you have to do yourself.

Editorial conclusion

Reach for this if you already depend on a com.squareup.retrofit2 build and want the lysine.dev line, and confirm the artifact your build resolved actually came from the repository you intended. Skip it if you are choosing an HTTP client from its README, because it shows no interface, no converter and no version alignment across modules. Before moving past 3.0.0, read CHANGELOG.md and the site at https://lysine.dev/retrofit/, since the trunk commits dated 2026-09-29 are not covered by any release note here.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes