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