Publish commit releases under the official groupId

[porunov]

Related discussion about publishing commit releases: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/discussion_release_snapshot/84922650
Related PR implementing publishing of commit releases to Maven Central Repository under org.janusgraph.commit groupId: #3364
Related obsolate PR implementing publishing of commit releases to GitHub Maven Repository under official org.janusgraph groupId: #3357

This thread is to discuss if we need to publish commit releases under org.janusgraph groupId or not.
The potential problem with org.janusgraph.commit groupId I'm thinking of is that transitive dependencies to JanusGraph may use org.janusgraph groupId and not org.janusgraph.commit groupId. In case user want to use the latest package from org.janusgraph.commit groupId they may add this dependency to their build tool, but in case user also have some other dependency which is using org,janusgraph groupId then users will get both JanusGraph versions from org.janusgraph and org.janusgraph.commit group ids.
The only way I see for the user to compile the project correctly is to search for any org.janusgraph transitive dependencies, exclude them, and add the same dependencies with a different groupId (org.janusgraph.commit). This should work but it might be challenging for some users I think.

I see several potential solutions to this problem:

1. In addition to org.janusgraph.commit groupId which is published to Maven Central we start publishing commit releases with org.janusgraph groupId to GitHub Maven Repository (the initial implementation was [OBSOLETE] Publish snapshot packages to GitHub #3357). Cons: Users need to authenticate with GitHub access token to use such packages; Packages with less than 5000 downloads may be removed by us (unlikely, but possible).
2. In addition to org.janusgraph.commit groupId which is published to Maven Central we start publishing commit snapshot releases with org.janusgraph groupId to Sonatype. Cons: we will need to add -SNAPSHOT suffix to such releases; These packages may be removed by us (unlikely, but possible).
3. Instead of publishing commit releases with org.janusgraph.commit groupId we start publishing commit releases directly with org.janusgraph groupId. Cons: users searching Maven Central for the necessary release to use might be confused which release to use; Dependabot may be confused about such frequent JanusGraph releases as well.

All these 3 solutions have their pros and cons. I don't know which solution is better. I guess solution 1 or 2 is less problematic because we don't break Dependabot workflow (i.e. we won't start spamming about new JanusGraph commit releases as with solution 3).
I guess if to choose then I would have preference either for solution 1 or solution 3. Solution 1 is less destructive, solution 3 may require some announcements ad explanations regarding a new way of bringing JanusGraph releases.

Would be great to hear what the community thinks about it.

cc @JanusGraph/maintainers

Update:

PR implementing solution 3: #3376

[FlorianHockmann]

One question about the scenario with transitive dependencies that aren't using our commit releases: Won't users always get two packages in this case?
If the application uses a commit release like 0.6.3-COMMITTAG and a transitive dependency uses 0.6.2, then Maven will fetch both dependencies, or not?

Regarding solutions 1 and 2: I would prefer if we had one place where we push the commit releases, not two. So, we should either use GitHub packages completely or only Nexus (with whatever groupId). Pushing these to two different places (or with two different groupIds) just makes our setup harder to maintain in my opinion.

Dependabot shouldn't be an issue as it uses semantic versioning and should therefore ignore these commit releases completely since these are pre-release versions. If a project that depends on a JanusGraph packages currently uses a stable version like 0.6.2, then Dependabot shouldn't create a PR to update that to something like 0.6.3-COMMITTAG. If they however already use a commit tag, then Dependabot will probably create a new PR so that they always have the newest commit tag. That's however the desired behavior in my opinion.

In the end, I don't have a strong opinion either way. I would be ok with publishing to GitHub packages, to Nexus under org.janusgraph, or like it's right now to Nexus under org.janusgraph.commit.

[porunov]

One question about the scenario with transitive dependencies that aren't using our commit releases: Won't users always get two packages in this case?
If the application uses a commit release like 0.6.3-COMMITTAG and a transitive dependency uses 0.6.2, then Maven will fetch both dependencies, or not?

It really depends on your configuration. It could fetch both and then select some winner implementations using some strategies or just fail. Here is a good Gradle doc, but I'm sure something similar for Maven exists: https://docs.gradle.org/current/userguide/dependency_capability_conflict.html

Dependabot shouldn't be an issue as it uses semantic versioning and should therefore ignore these commit releases completely since these are pre-release versions. If a project that depends on a JanusGraph packages currently uses a stable version like 0.6.2, then Dependabot shouldn't create a PR to update that to something like 0.6.3-COMMITTAG. If they however already use a commit tag, then Dependabot will probably create a new PR so that they always have the newest commit tag. That's however the desired behavior in my opinion.

This is a great input. In such case, it seems that publishing everything under org.janusgraph have more pros than solution 1 or 2.
As Dependabot isn't a big issue and users can configure it however they like, it seems to me like an obvious choice. No authentication needed, no potential problems with transitive dependencies under different group ids, fixed releases without
accidental removal ability.

In such case I would be in favor of using choice 3 and just update the documentation and notify users about the new versioning (i.e. commit and official versions).
I'm going to prepare the PR with the change but if anyone have any concerns about publishing commit releases under org.janusgraph, please, share them.

[porunov]

PR implementing solution 3: #3376