-
-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project Status and Road to 1.0 #112
Comments
I noticed that progress e.g. on the reviewing of PR's seams to have stagnated. I don't want to complain about that, because this is obviously a project you are developing in your free time, but I wanted to offer my help with those tasks, as I use |
Note there has been an update worth reading at #225 (comment) for anyone wanting to knowing the current status and plans. |
Please see #242 for a proposal on how schemars's |
I'm very excited to see your push for v1.0 and have been testing the alpha versions in my project. Do you have a rough order-of-magnitude estimate for when v1.0 might be released, e.g. days, weeks, months? I'm trying to decide whether I should pin a specific alpha version in my crate in its soon-ish crates.io release or just wait for v1.0 before releasing mine - either way I'm fine, so please don't take the interest as additional pressure :) |
Definitely not days, possibly weeks, but realistically much more likely months. I was hoping that the "stable" version of JSON Schema would be ready soon so that schemars could use it as the default version, but I'm not aware of an ETA for that, so we may need to live with draft 2020-12 being schemars's primary version forever. That doesn't mean schemars won't be able to support newer versions, of course, so it's probably fine. |
I've been doing some thinking about how to support "generation of separate schemas for serialization/deserialization", and written up some notes in comments starting from #48 (comment) - feedback on them would be very welcome! |
I've been working on Schemars for a little over 2 years now - it's always just been a personal project of mine, which does mean its progress depends on my free time and motivation. But I am certainly still here, and plan to continue working on it!
With that in mind, I thought it was worth recording some thoughts about where I see the project going, and specifically what I think is necessary to reach something I can could version 1.0.
I'd love to reach a point where Rust library authors can implement
JsonSchema
on their public types (probably depending on feature flags), much like is commonly done forserde::Serialize
/Deserialize
. But I'm not comfortable encouraging this too much yet, as I don't think the Schemars API is quite yet stable enough - there are still some enhancements and changes that I would love to see implemented which may require breaking changes to the current API. So, to be comfortable in releasing Schemars v1.0, I'd like to be reasonably confident that all desired enhancements can be implemented without breaking changes. Ideally, there would never need to be a v2.0. Off the top of my head, I would like to have solutions for:generation of separate schemas for serialization/deserialization (Support generating multiple schemas (for serialize vs deserialize) from the same struct #48)DONE in v1.0.0-alpha.15differentiation of distinct types with the same name (Schemars overwrites declarations if there are structs with the same name #62)DONE in v0.8.14handling of different JSON schema versions/dialects (and how to handle future JSON schema versions), including JSON schema draft 2020-12 / openapi 3.1DONE in v1.0.0-alpha.6debug_*
helper methods onFormatter
that are useful for manually implementingDebug
Note that these do not necessarily have to be implemented for 1.0, I just need to know that they could be done without breaking changes. There are a few ways to achieve this - it could be a proof-of-concept implementation, or just an API proposal with a vague idea of how that API could be implemented.
There are some more "indirect" improvements I'd like to get done, like writing up some contributor guidelines to make it easier for people to create useful PRs. I'm also interested in looking into the performance of Schemars, in particular the compile-time performance, including
#[derive(JsonSchema)]
. I assume that the actual schema generation at runtime is rarely in a hot path, so runtime performance is less of a concern (but not unimportant!), I would be very interested to hear if you don't agree.And finally, I'd like to take this opportunity to thank the community contributors - all of the bug reports, enhancement suggestions, and code contributions have been a massive help, so thank you all! ❤️
The text was updated successfully, but these errors were encountered: