Adopting semantic versioning

[sosmo]

First of all, thank you for the project and your continued support of it! I've used borg for 3+ years now and it's been invaluable to me (for what it's worth I also donate through borgbase every year).

I'd like to propose a small change to borg's versioning philosophy. Background: I recently upgraded to v1.2, and afterwards noticed my latest backups contained gigabytes worth of stuff that was previously ignored. This had to do with the change to file paths that they get passed to filters - there's no longer a preceding "/", but I had regex rules that asked to ignore all "dist", "node_modules" etc files under the "/git" directory (but nowhere else, as I might for example want to backup "dist" directories elsewhere).

Things breaking during minor version upgrades such as this can be surprising, especially these days when semantic versioning is wide-spread. So my suggestion is, maybe the major / leftmost version number of the project could be increased every time there's a change that has the potential to mess with users' backup data? This would obviously cause the major version to bump much more often, but it would be a good way to signal users that they're migrating to a version that may contain changes that require action (not everybody regularly checks the changelogs otherwise, I know I didn't). It would also help OS maintainers so that they might not include breaking versions into maintenance updates.

I understand if changing the versioning scheme isn't attractive, but I'm sure it would reduce the amount of people getting caught off-guard by breaking changes. Perhaps borg2 would be a good time to also adopt semver?

[ThomasWaldmann]

It was a mistake that the pattern matching change was not pointed out more clearly in the 1.2.0 change log. We fixed that in 1.2.1.

We intend to do semantic versioning usually.

E.g. borg 2.0.0 is named like that, because it is very breaking (to the extend that you can't just continue using your old repos with it, but you'll need to create new repos and transfer archives from old to new). That's the severity that makes the major version change.

A change that maybe needs a little edit of your scripts (like in 1.1.x -> 1.2.0) is not of that severity, but of course the docs should be clear about it.

[sosmo]

Alright, that's great :)

A change that maybe needs a little edit of your scripts (like in 1.1.x -> 1.2.0) is not of that severity

I think this can be a bit of a gray area - changing paths wasn't that bad because it wasn't going to lose data in this case, and excess archives are deletable as long as you spot them early. But say that some kind of a CLI change was made into pruning and that could cause archives to be lost if users didn't update their scripts? I'd say that definitely warrants a major version bump even though it'd be just an interface change.

Anyway, seems like the versioning indeed already makes sense. I should try borg2 soon on my repo. Thanks for the response!