Going for 1.0
vorner opened this issue · comments
There were only mostly documentation changes over the last ~year. It's probably time to be brave and declare the library 1.0.
If anyone is watching the repository and has some objections, this is the right time and place to voice them.
TODO:
- Go over the API guidelines to check nothing glaring is left.
- Decide what to do with the unstable features (eg. support for weak pointers, see rust-lang/rust#60728)
- Decide on more formal rust version guarantees (currently, the crate supports rust >=1.26, but maybe we don't want to guarantee that much, it's ancient).
- See if it's possible to abstract the whole locking strategy instead of just the generation locks through a trait (#35).
- Go over the API and look if there are some methods or parts of API would be nice to deprecate/remove (things like
rcu_unwrap, which is a bit questionable) or some traits sealed/hidden so we don't stabilize ourselves into a corner. Maybe something like feature-dependent sealing (eg. seal byUnstableApitrait that is exposed with theunstable-apifeature).
As for the API, it seems fine. Few more traits were added to Guard, but these are probably not going to be used in practice anyway.
As far as I'm aware, there's no strong consensus on MSRV policy in Rust community. I'd try to keep the MSRV unchanged for as long as possible - provided maintenance burden stays within bounds of reason - and make sure that bumping MSRV is accompanied with minor version bump (1.0.x => 1.1.0). Luckily, you don't depend on anything so you don't need to worry about your deps bumping MSRV.
Bumping MSRV to the latest stable at the release moment is probably a good idea. I would suggest to wait until 1.45 is out so you can stabilize weak properly.
I know there's no strong consensus, that's why I'm not entirely sure what to choose, if I can't simply copy the majority 😇.
Anyway, I was thinking more like go for the first version of the 2018 edition (that 1.26 is still 2015 edition, which is mildly annoying by now to work with) and promise that I'd always support at least a year back or something. As I have no deps (well, there are some dev-deps) and the code is a bit low level, there really is not much reason not to be conservative about it. I should still check what depends on the crate ‒ I think at least tokio declared some MSRV policy of theirs and I might as well not to go over that.
I think I can keep weak under a feature (and then you'd need at least 1.45, of course).
I think I'll just declare this'll support Rust from 1.31 onwards for the life of 1.0 (that's the one which brought the 2018 edition).
1.0 got released.