Source: borgbackup Followup-For: Bug #809136 [TL;DR: keep borg in testing. let it be released with stable when streth gets released. use backports to ensure compatibility works across debian releases, if necessary (and it is not, right now!).]
Both as a user and developer of borg backup, I disagree with some of the comments made of borg in this bug report. Borg has actually shown great API stability since it forked from Attic. The change that occured was necessary, and was well documented in the release notes and the manual. (It should have been documented in the NEWS.Debian file in the Debian package as well.) It is also the *only* one that happened in over 15 releases since the fork from Attic. We can even still convert older, prehistoric attic repositories to borg without data loss. Furthermore, this only concerns the backup remote RPC protocol. The storage format is *still* compatible, all the way back to attic. If you have a copy of your repository, you can still backup to and from it. If your server is upgraded, it is true that you do need to upgrade your client, however (and vice-versa). But tons of backup software in Debian have that behavior: unison was already mentionned, but rdiff-backup also has the same problems. That is why we have backports: when the server side upgrades, we upgrade the clients to the backports version. It's annoying, but it works, and rdiff-backup has been in Debian for a long time. Those other backup softwares are way more popular, sometimes by orders of magnitude, than borg: https://qa.debian.org/popcon.php?package=rdiff-backup https://qa.debian.org/popcon.php?package=unison https://qa.debian.org/popcon.php?package=borgbackup Keeping borg from entering stable (or, more precisely, testing in this case) is exactly what we *don't* want here. If we keep borg from entering testing, we keep it from being backported. If we keep it from being backported, we make it *harder* for people to run the same version of borg across different versions of Debian. So we basically make the Debian package useless, which means people won't use it and will instead use the pip version. Is that what we want? I was looking at backporting borg from stretch to jessie, but if the maintainers are going to remove it from stretch, i'm certainly not going to bother, and that would be a shame... Finally, keep in mind that this is a problem only in Debian, and only if we have multiple, incompatible versions of borg in Debian. (Non-debian installs can use virtualenvs to install as many borg versions as they want.) Right now, we only have one version (0.29.0-2), and it's compatible between unstable and testing. If testing gets released right now, stable, testing and unstable are all compatible, and we have absolutely no problem. Furthermore, it's very likely that borg 1.0 gets released before stretch, so all those arguments will be completely irrelevant because borg *will* be API stable. This, in short, is a non-isse right now. If 0.28 was in stable and 0.29 in testing, this would be a bug, but then the fix would be a backport, not a removal from stable (which you can do, if you are really stuck, anyways). Now, can i open this bug about backporting? :) a. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
