RFC: v4 package name

[martinbonnin]

Question

As we're starting to think about 4.0, there's a question what to do with the current package name (com.apollographql.apollo3).

For some background, we changed it according to https://jakewharton.com/java-interoperability-policy-for-major-version-updates/ when going from 2.x to 3.x in order to allow having both versions in parallel.

But the 3.x -> 4.x transition is going to be a lot more compatible than the 2.x -> 3.x one and changing all the package names is not the funniest thing in the world. That raises the question whether it's worth the hassle of going through yet another package name change. 4.x will remove some deprecated symbols so there's the risk that older binaries will crash with NoSuchMethodError but maybe that's an acceptable risk to take if that saves the vast majority the hassle of changing the package name, Maven group id and Gradle plugin id everywhere?

And if we decide to change the package name, maybe it's worth going for something that's less verbose and more future proof like or com.apollographql.apollo or just apollographql?

I wish we could do polls in GitHub issues but doesn't look like it's the case so here's a poor man's poll. React to this issue with your favorite emoji (there's no other meaning to them than just the line they're matching with..). Or feel free to comment below!

• ❤️ keep com.apollographql.apollo3
• 👍 change to com.apollographql.apollo4
• 🚀 change to com.apollographql.apollo
• 🎉 change to apollographql
• 👀 other (comment below)

[calvincestari]

Is the 'chore' of this work mostly for our team or is there pain for the end-user too?

[martinbonnin]

@calvincestari It's mostly the same amount of work except there are a lot less maintainers than there are users 😅 . So if we were to minimize the global amount of energy needed to do the change, ❤️ (no change) is the best option. Only concern is in the long term it's weird to have this "3" lying around and it might create some confusion.

[StylianosGakis]

I kinda like the apollographql approach, which is very similar to what okio or okhttp does with the super simple namespace.
This does also give the potential room for growth to apollographql5 when that time comes if there is such a need for a non-backwards compat change. Again, the same way that okhttp3 exists.
So I wouldn't hate seeing it here too, it's not like com.apollographql.apollo gives any more context that we would be missing out on otherwise.
Just my opinion 😊

[BoD]

Closing this now as the first alpha of 4.0.0 is about to be released: we are keeping the com.apollographql.apollo3 package name to ease the migration to this version.

[martinbonnin]

Additional data point: transitive usages of Apollo Kotlin in maven central artifacts

It's ~40 but some of them are internal usages and others are grouped of artifacts so I would say ~10 transitive usages that will break if an app tries to update to v4 before the SDK had a chance to (or updates the SDK without updating itself).

As a comparison, guava has 35946 transitive usages so I think/hope we're fine to keep the package name

[martinbonnin]

Hi everyone, it's me again overthinking this! Some more thoughts while discussing this with @BoD and @LouisCAD this morning:

1. Having the same identifier for groupId, pluginId and package name has less cognitive load (only one identifier for all of them) (argument against apollographql because both the group id and plugin id must start with com.apollographql for maven central verification)
2. having a different version in the package name compared to the actual version is confusing (argument against com.apollographql.apollo3)
3. Short package names are easier to read in source code and less verbose (argument for apollographql)
4. Keeping the namespace (com.apollographql) as part of the package name enforces some kind of uniqueness. Because DNS is enforced no one can reuse the package name by mistake. It's still possible to fork under another groupId. (argument against apollographql)
5. Keeping com.apollographql.apollo3 is a bit of a lie because there are (not too much but still) binary breaking changes between 3 and 4. (argument against com.apollographql.apollographql3)
6. In a perfect world apollo-runtime should be apollo-client and have a .client package name.
7. Every change has a cost. (argument for com.apollographql.apollographql3)
8. We're missing tooling to make this whole process easier! (general constatation about life)

[martinbonnin]

It's me again 👋 . After hours of discussions and brainstorming, we've decided to backtrack and change the package name to com.apollographql.apollo.

This should be the last package name change for the project (famous last words!) and com.apollographql.apollo feels like a much better home for the years to come.

We were thinking of following OkHttp footsteps and keeping com.apollographql.apollo3. Alas, we're not OkHttp-level stable yet. Apollo 4 has binary breaking changes while OkHttp 4 had (almost?) none and keeping the package name would be misleading.

We're hoping for a future where tooling makes it easier to change the namespace when breaking change happen but unfortunately, it doesn't look like the ecosystem is ready yet. And the "keep the same package" versioning scheme felt like the safest bet, at least a widely used one today.

com.apollographql.apollo is also the package name that had the most votes as of today so that counts too :). Thanks again everyone who contributed that discussion!