Going for 1.0 - Githubissues

vorner commented 4 years ago

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:

[x] Go over the API guidelines to check nothing glaring is left.
[x] Decide what to do with the unstable features (eg. support for weak pointers, see https://github.com/rust-lang/rust/issues/60728)
[x] 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 by UnstableApi trait that is exposed with the unstable-api feature).

vorner commented 4 years ago

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.

CreepySkeleton commented 4 years ago

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.

vorner commented 4 years ago

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).

vorner commented 4 years ago

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).

vorner commented 3 years ago

1.0 got released.

vorner / arc-swap

Going for 1.0 #32