Circling back to what @petitminion raised here: I think MusicBrainz’s logic here is pretty nice and is something that would benefit our users even if they don’t use MusicBrainz.
The basic concept goes:
- A Release group is an album
- A Release is a version of that album (e.g. the Japanese print, the UK print)
In most cases, users will only ever have one Release from a Group, but it’s definitely possible they might have many different versions. In Apple Music, they handle this by putting a single entry (Release group) forward in the album view:
When you look at that group, you are taken to a selected Release. The release information is shown alongside the title of the Release group
At the bottom of this listing, you can see Other versions (other Releases) that are available to you.
I would suggest that following this pattern would lead to a lot less clutter and would ultimately make a much nicer experience for users. We can easily split this up into:
When a user uploads an album, we can use MusicBrainz to fetch this information if it exists or create a new Release group to contain the Release if there is no MBID.
In the frontend, users would mostly just interact with Release groups in the overview, then selected Releases in the album view.
Users should have the ability to add Releases to a Release group, which updates the
release_group ID in the database.
@mjourdan What do you think about this from a design perspective? Does this approach make sense? Or do you think it’s better to have releases remain completely separate entities. Ping @gcrk and @petitminion for a backend perspective and @wvffle for a frontend take.