Control: retitle -1 Block borgbackup migration to stable for now Hello everyone,
I have thought a lot about this situation and I still think that blocking migration to stable *for now* is the sensible solution. I do not want to remove borgbackup from Debian, or keep this blocker alive indefinitely, just to clarify that. The "opener" of this ticket was the situation that you cannot connect to a borgbackup-0.28.0 server with a borgbackup-0.29.0 client or the other way around. This alone - as David pointed out - should not normally qualify for a blocker. Solving this issue in the way upstream suggests (having a borg-0.28 and a borg-0.29 command) would require changing installation paths so that both versions could coexist, and adding versioned binary names. While some work, that is not impossible, however it would still need "backports" of the old client versions to the current Debian sid, which may get a bit complicated and difficult to maintain. Now please keep in mind that borgbackup is *a backup software*. Users generally trust backup software with their most important data (we keep saying "make backups" for a reason) and even though the QA department says they should, most users don't test continually whether they can actually restore the backup with each new version of the backup software. I do not know if this is general consensus, but personally I would expect from any backup software included in Debian stable, that I can restore my data using the newer version in the next Debian stable. If a backup software does not qualify for that criteria, I would expect to be actively warned (versus requiring me to read the changelog) before I install/use it. Borgbackup currently does not meet that standard. In fact, they state "Expect that we will break compatibility repeatedly (...) like when going from 0.x.y to 1.0.0" on their front page in all-caps. You can read some discussion about backwards-compatibility in upstream issue #1 on github. I think it's safe to assume that once borgbackup reaches milestone 1.0.0, they will care a lot about (at least read-only) on-disk backwards compatibility, and maybe even RPC compatibility between 1.x and 1.y client/server. So this would be the time when I personally think it's ready for Debian stable. While it could be argued that with the same reasoning it should not be in Debian at all, I think having the package in unstable is actually beneficial both to Debian users and upstream development. I assume that a Debian *unstable* user is aware of the fact that this is relatively new software, and that a large portion of "unstable" userbase are developers and early adopters, that are willing to try new things out and submit helpful bugreports and feature requests. This kind of feedback can be very beneficial to upstream, and since those users will regularly update to the newest version, the backward-compatibility issue is not as present here. In essence, my main issue here is keeping up the high quality that users expect from a Debian stable. So unless we find some way to ensure users have read (and acknowledged) a statement about (non-)compatiblity before they install it, I don't think it should migrate into Debian stable until upstream starts to make that promise. This has been a rather long message, but I hope it clarifies the reasoning why I belive this is a blocker for stable migration. As always, discussion is appreciated and maybe someone has an idea or a solution I have not yet thought of. Thank you in advance, - Danny PS: Please don't CC me in replies, being co-maintainer I am subscribed to the bug.
