Is generated code safe to use across multiple Apollo versions?
January 27, 2021 at 7:37pmIs generated code safe to use across multiple Apollo versions?
January 27, 2021 at 7:37pm (Edited 3 months ago)For example, is it safe to assume a library/sdk that contains generated Apollo code from 2.4.1 can integrate into an app using Apollo 2.5.2? Gradle in this scenario will upgrade Apollo 2.4.1 in the library to 2.5.2, resulting in it reading generated code from an older version. This will certainly break when going too far back in versions, but I'm more curious about the recent + future versions of Apollo.
If it's not deemed safe, it would seem the only solution (which most SDKs should then do) is to shadow/rename Apollo + the generated classes in the library, correct?
January 27, 2021 at 10:49pm
Hi Daniel 👋.
Gradle in this scenario will upgrade Apollo 2.4.1 in the library to 2.5.2, resulting in it reading generated code from an older version.
If I understand correctly, the generated classes (from the lib) will be compiled against 2.4.1 and end up in lib.jar. At runtime these classes will run against 2.5.2
This transition should be fairly safe. More generally, we try to follow semantic versioning. While there might have been some exceptions in the past, we now have tools like metalava and japicmp to ensure API's are backward compatible. Furthermore, the generated code uses only classes from the
apollo-api module which is a relatively small part of apollo-android that moves less frequently so it should really be safe.Shading the whole library is a last resort option as that will duplicate some bytecode. I'm not too familiar with the shadow plugin but I think you'll have to relocate
com.apollographql.apollo in the lib module (where generated classes are) as well as apollo-runtime and apollo-api (and other support artifact like coroutines if you use them).I'm hoping you won't have to do that though. As said above, I'm fairly confident 2.4.1 -> 2.5.2 works well. Let us know how that went!