4 ms·
Am I misunderstanding this, or will it break dependencies that actually rely on the “rarely used api”? Seems to me like this trick is just to get the compiler t
by cortesoft 2y ago
Am I misunderstanding this, or will it break dependencies that actually rely on the “rarely used api”? Seems to me like this trick is just to get the compiler to ignore semver?
- aldonius 2y agoI see it not so much as getting the compiler to ignore semver but rather giving it more granular information about the nature of the changes. As I understand it: - Anything which is breaking-changed in any way for 0.3.0 (e.g. in the article a type change from i32 to u32) is the exact same code in 0.2.1 as it was in 0.2.0. - Anything which stays the same for 0.3.0 is re-exported in 0.2.1 (from 0.3.0). The code is replaced with a `pub use ...;` - Anything which moves around in the submodule hierarchy (but is otherwise unchanged) in 0.3.0 is re-exported in 0.2.1, from where it used to be. If crate Baz depends on something in Foo 0.2.x which changes in Foo 0.3.0, then when (if!) Baz updates to Foo 0.3.0 it will need to deal with that. But Baz can upgrade to Foo 0.2.1 without concern, and any types unchanged in Foo 0.3.0 will be interoperable.
- felurx 2y agoYou only re-export the unchanged parts. EVFILT_AIO is the same in 0.2.0 and 0.2.1 (which is different - in practice and to the compiler - to EVFILT_AIO in 0.3). (Only) c_void is the same in 0.2.0, 0.2.1 and 0.3 (again, in practice and to the compiler.)
- cpeterso 2y agoAnd the user can postpone making their code work with u32 EVFILT_AIO until they update from v0.2.* to v0.3.