gh-uuid-rs/uuid

Watch

Fork 0

Bring back the renamed `use_std` feature for backwards compat #157

Merged

sgrif merged 1 commit from sg-use-std-shim into master

2018-02-28 19:02:43 -06:00

sgrif commented

2018-02-28 17:16:47 -06:00

(Migrated from github.com)

addaecd0fc
removed this feature, which was intentionally left deprecated for
backwards compatibility. This "cleanup" removed a deprecated feature
before any released version actually had the deprecation present.

Removing this feature makes it impossible for other crates to support
UUID 0.6 without dropping support for UUID 0.5 and earlier. This is a
major problem for crates like Diesel, which are post-1.0

addaecd0fc9a1dbb053420ff91ed61ec1fc31395 removed this feature, which was intentionally left deprecated for backwards compatibility. This "cleanup" removed a deprecated feature before any released version actually had the deprecation present. Removing this feature makes it impossible for other crates to support UUID 0.6 without dropping support for UUID 0.5 and earlier. This is a major problem for crates like Diesel, which are post-1.0

radix (Migrated from github.com) reviewed

2018-02-28 17:16:47 -06:00

Dylan-DPC-zz (Migrated from github.com) reviewed

2018-02-28 17:16:47 -06:00

kinggoesgaming (Migrated from github.com) reviewed

2018-02-28 17:16:47 -06:00

KodrAus commented

2018-02-28 17:19:54 -06:00

(Migrated from github.com)

Ah my bad! I thought that feature was already published in the deprecated state.

Do you mind adding a comment to the toml to note that it's a shim for compatibility between ~~0.4 and 0.5~~ 0.5 and 0.6? (Did it again!)

Ah my bad! I thought that feature was already published in the deprecated state. Do you mind adding a comment to the toml to note that it's a shim for compatibility between ~~`0.4` and `0.5`~~ `0.5` and `0.6`? (Did it again!)

sgrif commented

2018-02-28 17:59:04 -06:00

(Migrated from github.com)

Done!

kinggoesgaming commented

2018-02-28 17:59:30 -06:00

(Migrated from github.com)

Note though we will most likely remove it before 1.0. Should be enough time for crates to adapt

sgrif commented

2018-02-28 18:01:56 -06:00

(Migrated from github.com)

I would argue that keeping this compatibility shim is incredibly low maintenance, and is worth keeping given that this is a crate that is likely to be a public dependency of others. But ultimately it's your call :)

KodrAus (Migrated from github.com) approved these changes

2018-02-28 18:14:34 -06:00

KodrAus (Migrated from github.com) left a comment

This looks good to me! Thanks @sgrif

kinggoesgaming commented

2018-02-28 18:25:05 -06:00

(Migrated from github.com)

@sgrif I would love to have it removed in 1.0 maybe add a note that this bound to be removed in the future.

Something like use_std = ["std"] # Compatibility shim for 0.5 and earlier. May be removed in the future. Use std instead

As uuid@1.0.0 is still quite a bit away, plenty of time to adapt :)

After discussion with @KodrAus, we decided to leave that as a release notes warning

@sgrif I would love to have it removed in `1.0` maybe add a note that this bound to be removed in the future. Something like `use_std = ["std"] # Compatibility shim for 0.5 and earlier. May be removed in the future. Use std instead` As `uuid@1.0.0` is still quite a bit away, plenty of time to adapt :) --- After discussion with @KodrAus, we decided to leave that as a release notes warning

KodrAus commented

2018-02-28 18:56:02 -06:00

(Migrated from github.com)

bors r+

bors[bot] commented

2018-02-28 19:02:42 -06:00

(Migrated from github.com)

Build succeeded

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

Dylan-DPC-zz commented

2018-03-01 02:13:03 -06:00

(Migrated from github.com)

hi @sgrif thanks for the PR. This is something that slipped through. We will maintain the compatibility shim in future releases.

@sgrif I would love to have it removed in 1.0 maybe add a note that this bound to be removed in the future.

@kinggoesgaming yeah true but then users won't know about it. Not everyone will check the toml file. Instead we can put a warning in the docs & readme.

hi @sgrif thanks for the PR. This is something that slipped through. We will maintain the compatibility shim in future releases. > @sgrif I would love to have it removed in 1.0 maybe add a note that this bound to be removed in the future. @kinggoesgaming yeah true but then users won't know about it. Not everyone will check the toml file. Instead we can put a warning in the docs & readme.

TethysSvensson commented

2018-03-01 04:05:08 -06:00

(Migrated from github.com)

Wouldn't you be able to use the semver-trick to remove the feature flag from new releases while keeping backwards compatibility?

Wouldn't you be able to use the [semver-trick](https://github.com/dtolnay/semver-trick) to remove the feature flag from new releases while keeping backwards compatibility?