Remaining works for 1.0 release
tisonkun opened this issue · comments
Hi @pacman82,
Thanks for providing atoi in Rust! I can see that tokio-rs/mini-redis relies on this crate and wondering what are remaining works for 1.0 release in your mind?
If you can list out the remaining works, it's possibly that volunteers take part of them and move forward. Or if it has delivered a good set of features, why not call it a 1.0.
Let me ponder on that for a bit. A 1.0 is for me a promise that the interface is stable. People seem happy enough with the feature set as it is now, though.
Would you have done anything differently with regards to the interface?
Also would you needing a newer Rust version to compile, consider a breaking change? I could see this crate using const fn more.
Other than that, if having a 1.0 increases the value of this crate to you, I am happy to fully stick to semantic versioning from here on out.
Released Version 1.0.0. Made minimal Rust version part of the contract for semantic versioning. It is currently set to 1.56.0.
@pacman82 thanks! I'm working with atoi today when patching mini-redis and doesn't see a block on using it.
As for me, a 1.0 release means that the author is confident that users can rely on the crate in any serious scenario. We can always add new features if necessary and breaking change is possible by bumping major version :P
For me a 1.0 is a sign that the interface had been figured out well enough, and should not be expected to change in a fundamental way frequently.
E.g. I would consider odbc-api very much production ready, but I have many changes in mind which would require a major version update in the future. So not making it 1.0 is my way of telling the users, expect the interface to change. Since I try my best to practice Continus Integration and Test Driven Development, I hope that any featured offered via and deployed to a package manager is reliable enough to be used in any scenario, wether there are upcoming changes in the interface expected, or not.
Offering a 1.0 also forces me to come up with the definition of the contract I am supposed to keep. E.g. wether I would consider requiring a newer compiler breaking or not. I prefer to do this later in the lifecycle, depending on the type of crate.
Sure enough, the interface of atoi hasn't changed much recently, so giving it a 1.0 is a reasonable thing to do. Thanks for giving me the impuls.
Cheers, Markus