gh-uuid-rs/uuid

Watch

Fork 0

Remove deprecated "use-std" #280

Merged

Dylan-DPC-zz merged 1 commit from refactor/remove-deprecated-feature into breaking

2018-07-17 07:52:07 -05:00

Dylan-DPC-zz commented

2018-07-13 06:39:26 -05:00

(Migrated from github.com)

I'm submitting a(n) removal

Description

feature use-std was renamed earlier in #108 and brought back and marked deprecated in #158. Removing it now

#108, #158

**I'm submitting a(n)** removal # Description feature `use-std` was renamed earlier in #108 and brought back and marked deprecated in #158. Removing it now # Related Issue(s) #108, #158

radix (Migrated from github.com) reviewed

2018-07-13 06:39:26 -05:00

KodrAus (Migrated from github.com) reviewed

2018-07-13 06:39:26 -05:00

kinggoesgaming commented

2018-07-13 18:03:08 -05:00

(Migrated from github.com)

I am not really comfortable with removing it quite yet. I think we should reserve this for 0.8 and aggressively advertise the removal in 0.7.0

@KodrAus opinions?

I am not really comfortable with removing it quite yet. I think we should reserve this for `0.8` and aggressively advertise the removal in `0.7.0` @KodrAus opinions?

Dylan-DPC-zz commented

2018-07-14 00:41:03 -05:00

(Migrated from github.com)

aggressively advertise the removal in 0.7.0

Deprecating something is aggressively advertising people to remove it.

> aggressively advertise the removal in 0.7.0 Deprecating something is aggressively advertising people to remove it.

kinggoesgaming commented

2018-07-16 11:39:51 -05:00

(Migrated from github.com)

I am not strictly against this... but would love some opinion from people who use this library (especially those who provide stability guarantees like 1.0+). We might ~~accidently~~ definitely break the dependents of those libraries, and pretty much contribute to the dependency hell.

The way I think the way to go would be for 0.7 we have warnings in the release notes and in main crate documentation, and then in 0.8 (which is meant as a breaking change to touch the public API so that it conforms with Rust API guidelines, see #191). Since this is technically a public API wart, we should go this way.

Again I am happy if this gets merged in 0.7, but just want a smoother transition for users. We are already covering a huge surface area with 0.7.

We might add a build.rs script with the following in 0.7:

fn main() {
    println!("cargo:warning=r#"[uuid] feature gate "use_std" is deprecated and is marked for removal. Use feature gate "std" instead."#);
}

Edit: added some more info.
Edit 2: added suggestion about build script warning.
Edit 3 and 4: typos 🤦‍♂️

I am not strictly against this... but would love some opinion from people who use this library (especially those who provide stability guarantees like `1.0+`). We might ~~accidently~~ definitely break the dependents of those libraries, and pretty much contribute to the dependency hell. The way I think the way to go would be for `0.7` we have warnings in the release notes and in main crate documentation, and then in `0.8` (which is meant as a breaking change to touch the public API so that it conforms with Rust API guidelines, see #191). Since this is technically a public API wart, we should go this way. Again I am happy if this gets merged in `0.7`, but just want a smoother transition for users. We are already covering a huge surface area with `0.7`. We might add a `build.rs` script with the following in `0.7`: ```rust fn main() { println!("cargo:warning=r#"[uuid] feature gate "use_std" is deprecated and is marked for removal. Use feature gate "std" instead."#); } ``` Edit: added some more info. Edit 2: added suggestion about build script warning. Edit 3 and 4: typos :man_facepalming:

Dylan-DPC-zz commented

2018-07-17 01:56:56 -05:00

(Migrated from github.com)

The users know that 0.7 is an breaking change, so they will expect stuff to break. Also most people use "0.6" as their dependency selector (if they use anything else such as *then there are multiple things which will already break their API), so it is not that this change will break their API overnight, and they will not just change the version from 0.6 to 0.7 without going through the list of things that have changed (which already consists of multiple API changes in the crate).

The users know that 0.7 is an breaking change, so they will expect stuff to break. Also most people use `"0.6"` as their dependency selector (if they use anything else such as `*`then there are multiple things which will already break their API), so it is not that this change will break their API overnight, and they will not just change the version from 0.6 to 0.7 without going through the list of things that have changed (which already consists of multiple API changes in the crate).

kinggoesgaming (Migrated from github.com) approved these changes

2018-07-17 07:44:57 -05:00

kinggoesgaming (Migrated from github.com) left a comment

Fine 🙄

kinggoesgaming commented

2018-07-17 07:45:15 -05:00

(Migrated from github.com)

bors r+

bors[bot] commented

2018-07-17 07:52:07 -05:00

(Migrated from github.com)

Build succeeded

# Build succeeded * [continuous-integration/travis-ci/push](https://travis-ci.org/uuid-rs/uuid/builds/404886054?utm_source=github_status&utm_medium=notification) * [continuous-integration/appveyor/branch](https://ci.appveyor.com/project/KodrAus/uuid/build/1.0.774)