` i think puttinginternal` in package name is a good practice
The project should better demarcate what is API and what is not
Currently it is not crystal clear what is API and what is not.
Clearly top level classes such as GraphQL and ExecutionStrategy are API
But what about
graphql.execution.ValuesResolver. Are they API or implementation detail?
If we had to add new aspects to these classes and changed constructors etc are we breaking consumers?
I suggest that the API be made more clear.
Annotations are a great way to do this. The project could have 3 new annotations
(things you can call and wont change) (things you are meant to implement) (public things that are not API and may change)
This will allow the project to better keep
semver sematics while evolving as necessary.
- weixin_39557813 4月前
regarding点赞 评论 复制链接分享
- weixin_39830205 4月前
I agree on .internal in the package name as well as .api in the packages however that would be a major breaking change.
Ideally it would be
the use of annotations are a way to not break current API while better documenting what is API点赞 评论 复制链接分享
Because we are planning for a breaking change release I suggest that we use that to try to make it more clear what api vs internal is.
But I think moving everything is not acceptable imho. Breaking stuff should be limited to what we think is really necessary. Annotating seems fine.点赞 评论 复制链接分享
I like the idea to add two annotations
andfor example.点赞 评论 复制链接分享
First shot: #411点赞 评论 复制链接分享
we added annotations in #411 ...closing it therefore now: we will add the annotations as we go.点赞 评论 复制链接分享