Migration Guide + Why?

[parsonsmatt]

I was unable to find any migration guide for bugsnag-haskell to bugsnag and bugsnag-hs. I'm planning on writing one up.

As I'm starting the migration process, I can't help but feel like it's a downgrade. bugsnag-haskell seemed to have a nicer, more user-friendly API. Why the switch?

[pbrisbin]

A migration guide would be great!

This was a long time ago, but IIRC...

It struck me as problematic that myself and the author of bugsnag-hs would both be maintaining Haskell types to mirror the Bugsnag API. It's a large API, why would we duplicate this effort? bugsnag-hs had had more coverage, I think it was 100%, and my own types were not. So I decided to just use it and stop maintaining anything of my own. This seemed strictly better (due to the more coverage) except for the un-prefixing of names, which didn't bother me. Is that all you mean by "nicer, more user-friendly API", that the types were prefixed, or is there more to it?

The split in -wai and -yesod was simply to avoid a heavy dependency foot-print for users of Bugsnag in a non-web context (we have a Background Jobs service that uses it, for example).

[parsonsmatt]

I understand the desire to avoid work and rely on another API. I just wish they'd stopped instead of you ;)

bugsnag-haskell had exposed constructors, allowing for RecordWildCards and a generally easier time with construction/extracting data. That's another difference.

I'll have more to say when I'm farther along, I'm sure

[parsonsmatt]

(nvm, will make another issue)