strawberry-graphql
Include documentation versioning
Feature Request Type
- [x ] Core functionality
- [ x] Alteration (enhancement/optimization) of existing feature(s)
- [ x] New behavior
Description
Recently at the company I work at we have started developing using strawberry due to its compatibility with FastApi and its ease of use in general. However, we have encountered several problems while developing since the documentation always makes reference to the latest version of the API.
This causes some issues, since when developing following the documentation, some examples shown may not be available in the version with which we work with (this is also due to the high amount of releases in the spam of a few months, great work there btw!).
This also does not greatly align with the idea of backwards compatibility. Some examples that come to mind are the inclusion of @strawberry.Maybe types or the removal of execute_sync.
Thus I think that to keep and increase the ease of use of the API, documentation versioning would be greatly beneficial both for maintainers and API users.
I would love to help in this arena if the idea is supported and help is needed!
Ty again for the great work!
This also does not greatly align with the idea of backwards compatibility. Some examples that come to mind are the inclusion of @strawberry.Maybe
btw, maybe will change slightly, see #3961
I think we should do this, I was thinking of migrating Strawberry from vercel to cloudflare, maybe we tackle versioning and migration in one go 😊
I guess we do:
https://strawberry.rocks/docs -> always latest
https://strawberry.rocks/0.211.1/docs docs for 0.211.1?
would that work?
Yes I think that approach would be lovely, one on latest and versioning paths for the specific releases!
In response to #3961, I fully agree with the proposal since I believe it would make much easier working with those types without the need to check the .values property and the nullability (it ends up being a little verbose when correctly accessing the values inside Some)
If there's anything I can help with I would be happy to do so!!
Ty for the quick response!
EDIT: After checking further the proposal for #3961, I see that some of the logic still applies but regardless I like the approach you go towards!
After checking further the proposal for https://github.com/strawberry-graphql/strawberry/pull/3961, I see that some of the logic still applies but regardless I like the approach you go towards!
feel free to drop a comment there if there's anything we should change 😊
We should keep in mind to only index the latest version on google for better results. Additionally, this would be a perfect topic for the 1.0+ releases - one doc version with every major sounds tidy to me 😊
@patrick91 forgive the delay, I have left some ideas related to #3961 in issue #3983