Hello Antoine, thank you for your detailed answer. I will try to address inline.
On 01/08/2016 10:45 PM, Antoine Beaupré wrote: > 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. My statement that borgbackup does not make any compatibility guarantees was a quote taken from the top-level README.rst (near the bottom of the file), not by inspecting the actual source code history. If it is no longer accurate, you might want to update that paragraph in the upstream README, since this statement reads very different. I apologize if I made the wrong conclusions, and I think we can find a good solution to this. > 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). Thank you for the clarification, I will include this in README.Debian and (in future releases, if there is another incompatiblity) in a NEWS.Debian. > 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: I understand this solves the issue about writing to a new (testing/unstable) server with an old (stable) client. I know this is irrelevant if borg-1.0 gets released before stretch (which I hope it does), but can you clarify how borg does/will handle "old server, new client"? > 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? Very good point. No I don't want to end up there. On a Debian system, the installed software should be managed by apt/dpkg. > 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... A backport would be really nice to have, so please don't give up on this yet. In essence, all I want is a solution on how to ensure that users don't get surprised. > 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. Agreed. Currently there would not be a problem, but it will be one when upstream releases another API-breaking release. The main point of this ticket is to figure out how to be prepared for that next time it happens. > 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. Yes that would be perfect. > > 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. Let's resolve this situation first and close this bug (so the testing-autoremoval is disabled), then create the backport. Let me try to summarize to check if I understood you correctly: 1. The incompatibility warning from README only affects the network communication between different versions, not the on-disk format 2. Borgbackup already makes the "read back your old backups with a new software version" promise, all the way back to attic repositories. 3. By using your backport, #1 will be solvable by the enduser directly without having to resort to non-apt-managed software installation. #1 would in my opinion downgrade this ticket from serious to normal, and #2 would make my point of "not ready for Debian stable" void. #3 would classify as a solution to #1, closing the bug. If that is accurate, I'd consider this more of a misunderstanding than an actual problem, and the solution would be a well-clarified README.Debian that explains to the end-user that for network communication they need to run the same version on all hosts (using backports when neccessary), and - from now on - NEWS.Debian entries whenever any incompatibilities arise, so users get notified at the "apt upgrade" stage and can abort the update if needed. I again apologize for any misunderstandings and look forward to your clarification. - Danny
