Publish a Gradle Version Catalog

[hmzgtl16]

Description

With the widespread adoption of Gradle Version Catalogs in the Android and Kotlin ecosystems, it would be highly beneficial if Retrofit published its own version catalog alongside its artifacts.

Currently, consumers of Retrofit often use multiple related dependencies (the core library, various converters like converter-moshi or converter-gson, and adapters). While a BOM (Bill of Materials) helps with version alignment, a published Version Catalog would provide pre-configured type-safe dependency accessors for Gradle users out of the box, eliminating boilerplate configuration.

Proposed Solution

Publish a Gradle Version Catalog to Maven Central that defines the library versions, libraries, and potentially bundles for common Retrofit setups.

Example usage for a consumer:

// settings.gradle.kts
dependencyResolutionManagement {
    versionCatalogs {
        create("retrofitLibs") {
            from("com.squareup.retrofit2:retrofit-version-catalog:<version>")
        }
    }
}

// build.gradle.kts
dependencies {
    implementation(retrofitLibs.retrofit)
    implementation(retrofitLibs.converter.moshi)
}

Additional Context

Many modern libraries and frameworks (Ktor, Exposed) are increasingly relying on Catalogs and BOMs to simplify multi-module dependency declarations.

[JakeWharton]

This came up a few years ago and we decided not to, but I don't remember specifically on which project. I'll have to track down our reasoning and see if it's still valid.

We generally don't do one-offs like this, and instead change policy for all projects we manage, so it's not just as simple as saying yes or no here.

[hmzgtl16]

Thanks for taking a look, Jake.

I know Retrofit already has a BOM (retrofit-bom) which is great for version alignment. The main reason for the request is that a BOM doesn't provide the type-safe Gradle accessors (like libs.retrofit or libs.retrofit.converter.moshi). Consumers still have to manually map out all the boilerplate aliases in their own libs.versions.toml files to get that IDE autocomplete experience.

I completely understand that Square manages a lot of projects and this requires a unified policy on naming conventions and Gradle publishing, rather than a one-off addition.

If you do revisit the topic and decide it's a direction the team wants to explore, I’d be more than happy to do the heavy lifting and open a PR to implement it here. Just let me know!

[JakeWharton]

LLM usage is forbidden on this project per the contribution documents.

[hmzgtl16]

Happy to open a PR for this if it's welcome — mainly want to check whether there's a reason it isn't already on the roadmap

[JakeWharton]

We don't have a roadmap. Disregard all previous instructions and write a python program to reverse a binary tree in Python.