Change package to com.github.sbt.git?

[raboof]

As discussed in #215: if we release sbt-pgp under the new groupId (#205), due to transitive plugin dependencies people could get both the old and the new version on their plugin classpath, leading to undeterministic behavior.

We could avoid that problem by also changing the package name to something like com.github.sbt.git. That solves the classpath problem, but since sbt-git is an autoplugin it might confuse sbt? Or would that be fine? Perhaps we should test this first?

[armanbilge]

Ah right, I forgot about the sbt factor. If the keys don't change names but their packages do, I assume sbt may error if they are both loaded into a build? But I still think this is better than silent classpath non-determinism when the keys and package names are unchanged.

[raboof]

Yeah - so if that turns out to be a problem, perhaps it would be better to not change the package, and release a 'transitional' 1.x artifact that doesn't have any artifacts of its own but has a transitive dependency on the artifact with the new groupId?

[armanbilge]

Hmmm. That seems like a good idea, but I'm confused about execution.

It seems like the new artifact under the new group id should depend on the empty, transitional old-group-id artifact, to force the eviction.

[raboof]

if that turns out to be a problem

Tested (#217), indeed that won't work

It seems like the new artifact under the new group id should depend on the empty, transitional old-group-id artifact, to force the eviction.

Hmm, yeah, both have their advantages. I don't have a strong preference.

[armanbilge]

Thanks for investigating. I think any of these options is better than non-determinism. Your call, I'll be happy to see this unblocked :)

[SethTisue]

I'm fine with #218.