So, not really sure which approach to take here. The problem: sometimes there are releases (often on Bandcamp) where the artist/label keeps adding new tracks over time.
every time the web release is updated, we mark the old MB release as Withdrawn and import the updated version from scratch as a new release, then link them using replaced-by relationships;
every time the web release is updated, we also update the MB release and add the new tracks (this is the approach I prefer).
Some editors seem to favour the first approach. I agree that it can make sense if the cover art changes or the release is renamed. But if it’s just the tracklist being updated, I feel that withdrawing and recreating the release is not only wasteful but also conceptually wrong. In some cases, we could end up with 12 or more Withdrawn releases in the same release group just because the artist kept adding new tracks — this creates unnecessary clutter in the database. It also doesn’t clearly communicate to users that the release they might have in their collection has been updated and now includes more tracks.
The second approach is cleaner (no clutter) and more conceptually accurate, since the Bandcamp release URL stays the same. The tracklist has changed, so we should reflect those changes in the MB release. Following Occam’s Razor — “Entities should not be multiplied beyond necessity” — is there really a need to follow the first approach?
If a release is explicitly being released as one that gradually releases over time, I think it’s best to have one entry, and use the annotation to mention the release was released gradually over time between date A and date B, adding x amount of tracks every y days/weeks/months.
But if a release gets corrected, adjusted, updated, … or something like that, I think the most proper approach would be to mark it as withdrawn and add a new, updated release.
A question. If you purchased the release, and then it got more tracks added, would you get those new tracks as part of your original purchase?
I see why people like the first option as they track the changes. This can be tricky for release dates as it is not always clear when the extra tracks get added. So you end up with a chain of releases where only one has a release date.
The alternate to keep one release makes sense to me IF this is still the item you originally purchased. If you get the new tracks for no extra cost I can see a logic to make one release, but something needs to be documented in the annotation.
I generally do the first approach for any tracklist changes (not just these progressive releases), as that properly sets the tracks’ recording release date
in theory, yes, but in practice, probably not
you can redownload the album, and it would almost certainly include the added tracks (don’t know for sure, as I haven’t done so yet), and you would see the new tracks in the Bandcamp app
that said, I would imagine a lot of Bandcamp users don’t often redownload old albums (unless they’re going from MP3 to FLAC or something), and I don’t know how many use the Bandcamp app to listen to music in their collections
I’ve stumbled upon this with one of my first MB submissions:
At some point the artist added 2 tracks to the album while keeping the public tracklisting the same, which Bandcamp shows by adding the following message below the release title:
Warning: 21 vs 19 tracks
At the time I chose to add the changes as a new release. I do see the arguments for option 2 as you’ve mentioned though. However, I think keeping track of changing tracklists for releases would be interesting (which adding a new release for each new version does, not sure if there are better ways of tracking this on MB…), but it seems hard to do for Bandcamp releases as I wasn’t able to find a way to get the date for when a given release was modified in such a way.
I’m also wondering what happens when a purchased release is changed at a later date. Thus far, that has never happened for any of the releases in my Bandcamp collection (the release above was a free download).
I believe this warning is actually the Bandcamp importer userscript
the date of the most recent change is available in the page source (or there’s a userscript which shows it on the page), I believe it’s the mod_date, but I could be misremembering the name
additionally, if there have been multiple changes, you can check the Wayback Machine, often you’ll find the mod_date of former versions
Seems like there’s no hard rule, but I’m seeing a general consensus that context matters, and I agree here.
I just set up a test Bandcamp artist page to see how this works in practice. If you add a track to a release, everyone who bought it earlier gets the new track automatically — it’s in the re-download. If you remove a track, it’s gone from the download too. So I think that makes a strong case for creating a new release when something gets removed, since some users will still have the older version with the now-missing track.
On the other hand, if tracks are just being added over time (like in a clearly progressive release), it feels more accurate — and a lot cleaner — to just update the existing MB release and note in the annotation that it was released gradually from date A to B.
The problem with tracking every single change as a new release is: we usually can’t know exactly when a track was added or removed. Bandcamp doesn’t show it, Wayback doesn’t always catch it, and even if you can scrape a mod date, that’s usually just the latest edit.
So yeah — for me:
Removals = new release
Additions = depends, but usually just update
And for slow-roll releases, I’m sticking with a single release + a clear annotation
Appreciate everyone’s input so far and please feel free to keep sharing if there’s more to it. The topic is by no means closed.
Unfortunate, but something we have to live with. The issue with updating previous releases is that you end up with, for instance, a song that was created in 2025 in the database as released in 2024. Better to add a new release and leave the release date blank - and consider using the release group release date in your tags.
P.S. For ridiculous “waterfall” releases I think waiting for the last track to be added and then setting that as the release date is fine - or at least fighting the OCD and just adding every few iterations
