Can we use a different package name for v2?

[lmeadors]

Would it be possible to use a different package name for v2?

As I understand it, the FQCN class name identifies the plugin to be used.

If the v1 and v2 names are the same, we will not be able to use both while migrating.

For those of us without unlimited clusters, that's not awesome.

[jcustenborder]

@lmeadors Hmmm I haven't thought about that. The goal was for v2 to be backwards compatible with v1.

[lmeadors]

I am trying a snapshot of v2 today in our development environment, but am a bit worried I will hose other things. Running them side-by-side would be less risky, even if they were compatible enough to just change the class name to move from v1 to v2 eventually.

...but I think I see another potential issue: If we move this to a "v2" package, that would make merging back to master messy.

I may have just talked myself out of this idea. ¯\(ツ)/¯

Unless you want to think on it or discuss this more, feel free to close the issue; thanks for the clarification.

[lmeadors]

@jcustenborder - I was thinking about this more.

Would a temporary "V2" suffix of the connector class names allow both to be deployed together? If so, that might solve both problems.

People (like me) could use both V1 and V2 together because the class lookups would be unique, then after a reasonable compatibility testing period, the suffix could be dropped.

Dropping that suffix might cause a bit of a disruption when upgrading to the V2 release, but only for people using both side-by-side.

For people only using one or the other (assuming the compatibility works well), no one would have to know.

PS: Please note the emphasis on "temporary" there, and if you are OK with this, I would be happy to send a PR your way with that refactoring.

[jcustenborder]

Well my goal was to keep the original class name and make it backwards compatible. I was going to log a warning telling you to move.