Update dependencies

[alastair]

This does a general upgrade of BU dependencies (as indicated by pip list --outdated). Some dev packages (pylint and mock) weren't upgraded to their latest versions since they don't support python2.

BU tests pass.

Don't merge this yet, I'll do some tests with AcousticBrainz based off this branch. We can then do the same with others to ensure that everything is working as expected.

[alastair]

This worked fine in AcousticBrainz. The only thing that needed to be changed is the name of a session variable in our temporary_login method: https://github.com/metabrainz/acousticbrainz-server/pull/371/files#diff-4d70e464f5bcc3de01e467bd1d018698R16-R19

user_id -> _user_id

[alastair]

@paramsingh thanks. I'd like to discuss with you some time what the steps are to release this, and the process for upgrading other brainzes. I seem to recall a discussion going on about LB recently too.

[paramsingh]

Sure, what questions do you have?

The release process is nothing special.

• Merge changes to master
• Update __version__ in brainzutils/__init__.py
• Create a github release (we use semantic versioning)
• Use the tag downstream.

It would be nice if we could host this on pip, but I never had the chance to do that.

[alastair]

This release will break tests in downstream apps. Does that mean it's a major change?

Have you ever written release notes for a release? Specifically I'm thinking about this change that has to be made - if we don't write anything then someone's going to upgrade the version for their downstream app and it'll fail with seemingly no indication as to why. I guess if we make a gh release we can add this as some text. Thoughts?

[paramsingh]

This release will break tests in downstream apps. Does that mean it's a major change?

I would say so, yes. We use semantic versioning: https://semver.org/

Have you ever written release notes for a release? Specifically I'm thinking about this change that has to be made - if we don't write anything then someone's going to upgrade the version for their downstream app and it'll fail with seemingly no indication as to why. I guess if we make a gh release we can add this as some text. Thoughts?

I do add release notes to the release. I'm happy if we keep doing that.