Replies: 1 comment 1 reply
-
|
Hi thanks for the suggestion, let me discuss it with the team. Yes I agree that the GraphQL Java version number isn't always matching for libraries such as extended scalars and validation, and Java Dataloader has another version numbering system altogether. I can see how that's confusing and inconvenient! For others reading this thread, please do add your comments or add an upvote and that helps me work out what to prioritise. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
A colleague at work also asked about a BOM so that's 1 more upvote! |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The core
graphql-javalibrary has a few companion libraries with aligned-but-not-matching version numbers.It would be convenient and reduce risk of error if developers could import a BOM to define versions for all relevant dependencies.
See this discussion from the spring team, which mentions some of the benefits: spring-projects/spring-graphql#242
Beta Was this translation helpful? Give feedback.
All reactions