Replies: 1 comment 2 replies
-
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? 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 In the end, I don't have a strong opinion either way. I would be ok with publishing to GitHub packages, to Nexus under |
Beta Was this translation helpful? Give feedback.
-
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: #3364Related obsolate PR implementing publishing of commit releases to GitHub Maven Repository under official
org.janusgraph
groupId: #3357This 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 useorg.janusgraph
groupId and notorg.janusgraph.commit
groupId. In case user want to use the latest package fromorg.janusgraph.commit
groupId they may add this dependency to their build tool, but in case user also have some other dependency which is usingorg,janusgraph
groupId then users will get both JanusGraph versions fromorg.janusgraph
andorg.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:
org.janusgraph.commit
groupId which is published to Maven Central we start publishing commit releases withorg.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).org.janusgraph.commit
groupId which is published to Maven Central we start publishing commit snapshot releases withorg.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).org.janusgraph.commit
groupId we start publishing commit releases directly withorg.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
Beta Was this translation helpful? Give feedback.
All reactions