1.3 / 2.0 Development #6713
Replies: 2 comments 1 reply
-
|
That 1.3 plan might well become 2.0, but that's just numbers. It's the next release after 1.2. As soon as we merge the breaking changes you see in In general, maybe don't hold your breath for indeterminate time. While there has been some major progress to fix a lot of "breaking" issues (see github labels), it's not in master yet, nor alpha, nor beta. So it could take a while. We have still some known breaking stuff to fix but we may find some more stuff not yet on the plan. And we want to fix all breaking stuff in one breaking release preferably, to minimise discomfort for the users [like time and space consuming data transfers / conversions], especially for the ones with large or many repos. Timing also depends on how many developers are helping with coding, code review (I could merge or improve stuff quicker with more / quicker feedback) and testing. It might also depend a bit on funding, which is currently rather low. But, you can start using borg 1.1.x or 1.2.x and later transfer your data to new repos. That transfer will need some time and space, but you don't need to watch it all the time. :-) About the milestones: these got mixed up quite a bit due to the plan to do a breaking release (which was triggered by the new crypto / getting rid of the old crypto and by the need to transfer all archives into a freshly built repo using fresh keys). And if we do that, it is the perfect time to also fix all other breaking issues that are on hold since many years. After the merge (or not-merge) of borg2 into master, I'll clean up the milestones accordingly. I hope that 2.0 will not take as long as 1.2 did, but can't make promises. And considering the improvements to the code base, crypto, etc. this would bring, I hope we won't need a 1.3 release. Current plan:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the thoughtful reply. Something I didn't realize is that the fix for the crypto roadmap might not be released until 2.0. I realize it is 'just' a number, but the scope of 2.0 is clearly much larger than that crypto fix. That is certainly information that makes me feel like it might not be quite as short as I was optimistically thinking for the crypto roadmap solution - but again, I am not trying to push one way or another. Also, thank you for boiling down the current plan. I don't mind trying to help as this project is clearly a great one, but I am afraid I am not sure how much help I am with code review with my limited (read: none) comprehension on the how borg currently works and limited understanding of encryption implementation pitfalls (although I do have some limited understanding of the principles). If you have thoughts on how despite that I would add more substance than noise, I would be happy to discuss/contribute. I didn't realize that funding was an issue. What are the project's desires/goals for additional funding to keep everything viable? |
Beta Was this translation helpful? Give feedback.
-
|
That "crypto fix" might be throwing out AES-CTR (and the counter management code, maybe also pbkdf2) completely (in N+1 release) and only working with sessions keys and AES-OCB/CHACHA20-POLY1305 and argon2. A lot of the borg internals are documented in the "internals" section of the docs, in case you want to help. Funding: bountysource org account is currently at 50 USD. Liberapay is at 115 USD/week. That's better than 0 definitely (thanks to all supporters, btw!), but not very sustainable when putting lots of work hours into the project. |
Beta Was this translation helpful? Give feedback.
-
Hi all. First let me thank the contributors for their effort. While I have used home-grown scripts for just under 20 years, I have had my eye on this project for at least three years. I have even protyped what repos I would use and their structure and I think they would be a really great use for me. I also got past the change from my scripts public/private key usage which I still prefer, but I understand moving buys me a lot more functionality from borg, particularly in defining much more easily moving periods of time of records for the backups. For example, I currently cannot say have retain 1 hour backups for the past day, 1 day backups for the past week, and monthly for the past six months. That also wouldn't be sane for me without de-duplicating features, which I do not have.
I realize that, of course, my last issue hasn't been a blocking issue for many, but the issue I had been tracking for years is #1044, the Crypto Roadmap. For various reasons, I chose to wait for that to be completed, secretly hoping it might make the 1.2 release. While it did not, it appears that (despite the fact it still shows only 6 of 7 tasks complete) this issue is now ready in the 1.3 (helium?) branch, especially when looking at PR #6463 and the issues it references as fixed.
I will likely be getting to a cross-roads here sometime in the next few months. My scripts are getting long in the tooth and require either investment to refresh some (a lot) of elements or move to borg. Hence, my dilemma: wait for 1.3 or rewrite my scripts. To be honest, I am loathing doing the rewrite path. Waiting for 1.3 seems somewhat a good idea at this point if I would go down the borg path, especially in light of the breaking repo format (v2) that will make an appearance in 1.3. The new format does look improved and I would be interested in using it. However, I am trying to figure out what time scale that might be. I understand it will be done when it is done, and I not asking for a deadline. Noting the release history of the project: 1.1.0 on 7 Oct 2017 and 1.2.0 on 22 Feb 2022 would seem to infer it will likely still be years before 1.3 is released. However, there seem to be several elements I can see that point to a change in that history, which is why I would like to enquire with the project.
I could be reading too far into the comments of issue #6707, but it seems like borg2 is where the real meat of work is targeting. Creating the branch with significant work on it typically makes merging other significant work into it more difficult, and assuming the project is not masochistic, this would infer that the project expects there will be a relatively short time and manageable scope of changes in the 1.X (namely 1.3) branch path. If it wasn't, then merging in those new 1.3 features into 2.X would be onerous. Additionally, the milestone for helium includes in the description "don't put too much in here, so we can release this in a short time.", and sure enough, there seem to be a relatively small number of issues targeted towards it. It is still a little unclear what versions are targeted by lithium and beryllium (not sure where the 2.X is being cut), but it seems reasonable to assume that helium is tied to 1.3 since hydrogen was ties to 1.2. Even the new 'roadmap' issue (#6602) seems to be much more concerned about limiting the scope of the release as to make it releasable in a more reasonable time.
So with all that, does the project wish to make any comments about its plans on the 1.3.X series of releases? Is it a reasonable inference that 1.3 will be released much sooner after 1.2 than 1.2 was after 1.1? Again, I am not looking to speed up the process, but rather gather as much information as I can to make an informed decision. Since the trend looks positive, I wanted to make sure that this was affirmed by the project and not my wishful thinking. Again, thanks again for providing the community a great tool!
Beta Was this translation helpful? Give feedback.
All reactions