codefromthecrypt
commented
9 months ago cc @anuraaga @shakuzen @reta just capturing thoughts here. as described this shouldn't happen this year.
Open codefromthecrypt opened 9 months ago
codefromthecrypt
commented
9 months ago cc @anuraaga @shakuzen @reta just capturing thoughts here. as described this shouldn't happen this year.
There are outside consumers of the sender libraries, so we should be careful about when we release zipkin-reporter 4, and possibly how we release it. It should be as late as possible, to impact folks least, and move the floor java version from 1.6 to 8.
on move from Java 1.6 to 8 floor: yes, when forced by toolchain
So, this shouldn't happen until after using JDK11 becomes a problem, noting official EOL may happen soon, but on the other hand, azul will likely support it for a long time. Remember JDK 11 is the last to support compiling Java 1.6.
on removing deprecation: yes, but that's not timeline driving
When we do reporter 4 we should also remove deprecated functions, however unlike reporter 3 deprecation removal isn't terribly important. In other words, we don't need to use deprecation as the reason to push 4, rather something around our ability to compile or run tests.
on package/groupId change: probably should
We might consider changing the group ID and even the package name when we release 4. We didn't on 3 because it would have been a lot of work due to complexity of the Call type. Since that isn't used anymore, we could consider abandoning the old package and move from reporter2 to reporter4 this time. This is because the sender is a very simple type now. If we did that, it would break people less, as they could still depend on both jars.