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
Going 1.0 #56
Comments
There is one more thing I have been thinking about on and off, and that is error reporting. We do a reasonable job in general, but what may be considered missing is more context. For example, when looking up an extension we may get an I believe that crates such as |
There is also |
I am cautiously confident that the code is moving towards a state where we can say it won't change in completely unexpected ways anymore (our experience with
argparse
is overall positive so we are unlikely to change that;nitrokey-rs
is obviously there to stay; we have our testing story flushed out). As such, perhaps it is time to roughly sketch out what we see as requirements for a 1.0 release candidate.The two big items I see are:
I don't think we need to have support for all the features that
nitrokey-app
orlibnitrokey
provides. However, I would like to see the following:We should also have at least considered the remaining features a Nitrokey supports, and have confidence that they will somehow fit into the existing command scheme or can be implemented as extensions in a sensible way.
It would be nice to only depend on
1.0
crates ourselves, but that is obviously out of our control to a large extent. However,nitrokey-rs
is still a bit in flux and I would definitely wait until @robinkrahl has not planned any more incompatible changes.If anybody has any thoughts/additions, I'd be happy to hear them.
The text was updated successfully, but these errors were encountered: