Failure 0.1.2 Release

[mitsuhiko]

I think master is ready for a release but I still need to get access to crates.io. I would love if people give the master version a try however since this library is light on tests currently.

[withoutboats]

I've created the @rust-lang-nursery/failure team to maintain this crate and added it as an owner, but I don't have the privilege to invite @mitsuhiko to join the @rust-lang-nursery organization.

[BurntSushi]

cc @alexcrichton

[alexcrichton]

Ok! @mitsuhiko you should be invited now and once accepting shoudl be a member of the @rust-lang-nursery/failure team, let me know if something is awry though!

[dekellum]

If anyone is in a similar circumstance with their failure dependency, please test like in dekellum/body-image@8118da3, per @mitsuhiko's request. Thanks!

[mykmelez]

I think master is ready for a release but I still need to get access to crates.io. I would love if people give the master version a try however since this library is light on tests currently.

It passes tests in the rkv crate per Appveyor and Travis CI.

[withoutboats]

Thanks for your help @alexcrichton

[mitsuhiko]

This brings up the question if a point release should deprecate cause() I suppose. But the name is really bad so I at least want to bring in as_fail().

[dekellum]

What we hope the testing would bring up. Yep, I think treating any new use of deprecate, in itself, as a breaking change is both counter-productive and extreme. So in other words I think deprecating cause() is fine to include in 0.1.2, in the spirit of, if not (potentially, haven't checked) the letter of semver.

[mitsuhiko]

I also want to introduce another deprecation through this: #231

That way users only have to suffer through the changes once.

[tismith]

I'm not sure a point release adding a deprecation is really in the spirit of semver, but either way - once the depreciation is taken care of, looks like https://github.com/tismith/exitfailure is passing ok - tismith/exitfailure#18 (appveyor still running).

[mitsuhiko]

I would love to not have that deprecation warning but I don’t know how to update everything to 0.2 without breaking the ecosystem otherwise.

[untitaker]

Not sure if intentional, but the backtrace feature is disabled by default in master while enabled by default in 0.1.1. This could be considered a breaking change.

[mitsuhiko]

@untitaker not intentional. Going to fix this.

[mmrath]

not able to use context on result. Is that an intentional breaking change?

[mitsuhiko]

@mmrath what do you mean by not being able to use context on result? The method still exists.

[mmrath]

@mitsuhiko Sample repo

When change version from 0.1 to git master I see an error like this. With 0.1.1 it compiles fine. other crates also have issues with the latest master i think.

note: the method `context` exists but the following trait bounds were not satisfied:
           `std::result::Result<bool, argonautica::error::Error> : failure::result_ext::ResultExt<_, _>`
           `std::result::Result<bool, argonautica::error::Error> : failure::Fail`
           `&std::result::Result<bool, argonautica::error::Error> : failure::Fail`
           `&mut std::result::Result<bool, argonautica::error::Error> : failure::Fail`
   = help: items from traits can only be used if the trait is in scope
   = note: the following trait is implemented but not in scope, perhaps add a `use` for it:
           `use failure::result_ext::ResultExt;`

[mitsuhiko]

That’s because you are not using the patch feature to replace it and you now end up with two incompatible versions of failure in the same app.

…

On Sun, Jul 29, 2018 at 11:31 AM Murali ***@***.***> wrote: @mitsuhiko <https://github.com/mitsuhiko> Sample repo <https://github.com/mmrath/fina-server/tree/failure-master> When change version from 0.1 to git master I see an error like this. With 0.1.1 it compiles fine. other crates also have issues with the latest master i think. note: the method `context` exists but the following trait bounds were not satisfied: `std::result::Result<bool, argonautica::error::Error> : failure::result_ext::ResultExt<_, _>` `std::result::Result<bool, argonautica::error::Error> : failure::Fail` `&std::result::Result<bool, argonautica::error::Error> : failure::Fail` `&mut std::result::Result<bool, argonautica::error::Error> : failure::Fail` = help: items from traits can only be used if the trait is in scope = note: the following trait is implemented but not in scope, perhaps add a `use` for it: `use failure::result_ext::ResultExt;` — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAc5GYSUO7_S7vgWjNdi75cvWeE_sW6ks5uLYEFgaJpZM4Vjhm6> .

[mmrath]

would you know how do i fix it?

[mitsuhiko]

Use the patch feature in cargo instead of using a git dependency directly. https://doc.rust-lang.org/cargo/reference/manifest.html

…

On Sun, Jul 29, 2018 at 11:56 AM Murali ***@***.***> wrote: would you know how do i fix it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAc5JiKABOcMw-1shv7RYur4fhTMDpBks5uLYbXgaJpZM4Vjhm6> .

[kyren]

Not sure if this is the correct place for this discussion, but with commit 3d5b8f9 does this mean that it will be impossible to use std features in failure without enabling backtraces? If so, that's much less useful than them being controllable separately.

Edit: After thinking about it for a moment, the situation that arose when I was trying to disable backtraces because the backtrace crate didn't work but std DID work was pretty unusual, so it's not exactly a compelling use-case. Disabling the backtrace feature can AIUI give a performance boost when using backtrace capturing errors in hot code though, so it might still be useful to other people to disable while still being able to use e.g. the failure::Error type.

[mitsuhiko]

@kyren that has been the behavior so far: https://github.com/rust-lang-nursery/failure/blob/version-0.1/Cargo.toml

[kyren]

@mitsuhiko Yeah, I'm aware it was the behavior in previous released versions. Disabling backtrace was actually the specific feature I was waiting on 1.0 for (but obviously plans have changed since then).

I don't remember where the discussion was, but iirc it was a planned 1.0 feature? I can try and find the original discussion, but it isn't super critical to me anymore anyway. If you would rather NOT have this behavior in the next release that's fine as well, but if it's easy to do, it would probably be useful?

If this thread is for discussing backwards compatibility though, this is probably wildly off-topic.

[mitsuhiko]

I just can’t change this in a minor release

…

On Tue, Jul 31, 2018 at 12:51 PM kyren ***@***.***> wrote: @mitsuhiko <https://github.com/mitsuhiko> Yeah, I'm aware it was the behavior in previous released versions. Disabling backtrace was actually the specific feature I was waiting on 1.0 for (but obviously plans have changed since then). I don't remember where the discussion was, but iirc it was a planned 1.0 feature? I can try and find the original discussion, but it isn't super critical to me anymore anyway. If you would rather NOT have this behavior in the next release that's fine as well, but if it's easy to do, it would probably be useful? If this thread is for discussing backwards compatibility though, this is probably wildly off-topic. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAc5J6PsMZUnDYtJHsuxz7FDPC16DEsks5uMDbNgaJpZM4Vjhm6> .

[dekellum]

An 0.2.0 release is still possible, and sufficient from a semver perspective, for @kyren's request, right? Of course 0.1.2 would be released first.

[kyren]

Ohhh, I didn't think about this enough. I was thinking that it would be sufficient to make the backtrace feature enabled by default but not via std, but I suppose form a semver perspective it would have to be enabled when std is enabled as well? It's not an API breaking change, and you'd have to already have disabled default features and be opting into std, but I suppose that IS still strictly a breaking change, darn. I hope I'm thinking about this correctly, if I'm missing some other obvious semver issue let me know, but I understand if even that one is sufficiently breaking.

Yeah, okay, I guess keep it in mind for a future 0.2 or 1.0 but otherwise sorry for the noise!

[withoutboats]

My understanding is that once rust-lang/rfcs#2504 is landed and stabilized, failure will upgrade so that users are expected to implement std::error::Error instead of failure::Fail. That will be a breaking change, but once it happens it frees failure from worrying about defining the shared interface used by all other libraries, and failure will be more able to make breaking changes as it evolves from then on.

[mitsuhiko]

I am going to release current master tomorrow. Last chance to give feedback.

With regards to std implying backtrace: i will have a look next release if we can do something there. In the ideal case the std feature does not actually do anything anyways.

[mitsuhiko]

This has been released.

[cauebs]

I'm sorry, I'm a bit out of the loop. What are the changes in this version?

[otavio]

@cauebs there was #241 adding the changes to the release notes. I hope it helps you.