refactor!: remove second opts argument in Honeybadger.notify

[joshuap]

This moves to keyword arguments exclusively. See #426 for further context.

BREAKING CHANGE: The following signature is no longer supported:

Honeybadger.notify("test", {tags: 'testing, hash'})

Instead, you must do this:

Honeybadger.notify("test", tags: 'testing, hash')

[subzero10]

👏 Kudos for the conventional commit PR naming style! With conventional commits, we can automate versioning, which will eventually help with automated releases.

There's one minor correction: everything should be lowercase:
chore!: remove second opts argument in Honeybadger.notify

Finally, I'm wondering if chore is the best commit type here; usually chores don't really come with breaking changes. Maybe refactor?

[halfbyte]

Looks good to me. Sorry @joshuap for not waiting for your comment, otherwise my PR could have been this, of course.

[joshuap]

Finally, I'm wondering if chore is the best commit type here; usually chores don't really come with breaking changes. Maybe refactor?

I'm not sure refactor is it since refactoring shouldn't introduce any changes, right?

[subzero10]

I'm not sure refactor is it since refactoring shouldn't introduce any changes, right?

Good point! Though, I usually prefer this definition, taken from here:
refactor => A code change that neither fixes a bug nor adds a feature
which could allow changes (?).

One additional point is that usually automatic changelog generation will ignore chore commit types (though we could add chores to the ruby changelog when we integrate with conventional commits).

[subzero10]

One additional point is that usually automatic changelog generation will ignore chore commit types (though we could add chores to the ruby changelog when we integrate with conventional commits).

@joshuap I confirmed that this is the case with our automated versioning and changelog generation on the ruby package. chore commits are ignored. So, I think it's best to change the title of this PR.

[joshuap]

One additional point is that usually automatic changelog generation will ignore chore commit types (though we could add chores to the ruby changelog when we integrate with conventional commits).

@joshuap I confirmed that this is the case with our automated versioning and changelog generation on the ruby package. chore commits are ignored. So, I think it's best to change the title of this PR.

done!