Version 0.6.6 breaking semver?

[gendx]

The freshly released 0.6.6 version (#20) causes this Travis-CI build to fail: https://travis-ci.org/google/OpenSK/builds/645900468

    Checking linked_list_allocator v0.6.6
error[E0432]: unresolved import `alloc::alloc::AllocRef`
  --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/linked_list_allocator-0.6.6/src/lib.rs:14:20
   |
14 | use alloc::alloc::{AllocRef, AllocErr, Layout};
   |                    ^^^^^^^^ no `AllocRef` in `alloc`
error: aborting due to previous error

This may be due to the fact that we pin a specific Rust toolchain - which didn't have the AllocRef symbol yet (indeed, the renaming in rust-lang/rust#68529 and rust-lang/rust#68736 was very brief, not leaving much time to migrate to the new name).

One could argue that given that the allocator API in unstable (#[unstable(feature = "allocator_api", issue = "32838")]) such breakage is expected from Rust's stdlib side.

On the one hand, linked-list-allocator >= 0.6.6 doesn't compile with old versions of Rust nightly. On the other hand, versions of linked-list-allocator < 0.6.5 won't compile anymore on new Rust nightlies due to the new name.

This seems to me like it could qualify as a semver breakage, as version ^0.6.5 can mean either 0.6.5 or 0.6.6 (depending on when one updated their crates), but in all cases (except the few days between rust-lang/rust#68529 and rust-lang/rust#68736 where Alloc and AllocRef both existed) either 0.6.5 or 0.6.6 won't compile (depending on the liballoc in the toolchain).

If instead a new 0.7.0 version is released and 0.6.6 is yanked, dependents of linked-list-allocator can choose between 0.6.x and 0.7.x according to their toolchain.

[phil-opp]

I'm sorry for the breakage. However, I'm not sure what the better option is. By releasing the change only as version 0.7.0 I would also break a lot of people because they are suddenly required to manually update their dependency.

I decided to release only a patch version (0.6.6 instead of 0.7.0) for the following reasons:

• As far as I know, most nightly projects use the latest nightly version on CI. By releasing a patch version, the CI continues to work without requiring manual updates to each project.
• Projects that pin an older nightly can still pin a specific version of linked_list_allocator by specifying =0.6.5 as version.
• Cargo does not auto-update dependencies, it only updates them on cargo update or when no lockfile is used.
• Fixing a compile error on the latest nightly can also be interpreted as a bugfix, which semver explicitly allows for patch versions.

I'm happy to discuss this though!

For the future, I think the best solution is to gate all uses of unstable features behind a unstable-features cargo feature and provide clear documentation what the stability guarantees for the feature are.

[gendx]

This totally makes sense, and in our case we're planning to upgrade the rust-toolchain, and linked_list_allocator to >= 0.6.6 (see google/OpenSK#10).

[phil-opp]

Great to hear that!

[gendx]

Closing as bumping our dependency resolved the issue for us.