Hello Eric, I think it's the best direction to branch out a future version 3.x. It gives more space for innovation and should greatly improve the speed of development.
As much as I would like to dedicate more time to rdiff-backup itself, my hands are really full with Rdiffweb and Minarca. Thanks alot for all your work. +1 for weekly releases Le sam. 6 mai 2023, à 07 h 08, EricZolf <ewl+rdiffbac...@lavar.de> a écrit : > Hi, > > after our recent discussions about the future of rdiff-backup, > compatibility back and forth, etc, I had to think about this before > taking a decision. > > Two points were important to me: > > 1. as maintainer, get new participants to the code, I don't have a lot > of time and I'm a liability if I'm the only one understanding the code. > I want to be able to leave the project at any time with the good feeling > of someone being able to take over. > > 2. as user, speed is my main issue with rdiff-backup, it could surely be > faster (and I don't think anybody would complain either), else it does > what I expect. And it is a principle of (non-commercial) open source > that you're motivated as maintainer by what you need as user. > > So, in order to reach these two targets, I must: > > 1. simplify and document the code properly > 2. make the code more modular so that people can participate without > having to understand the whole code (plugins architecture or similar) > 3. even better understand the code to be able to optimize it > 4. assuming parallelization and/or async I/O are on the path to better > performance, it'll be a complexification of the code, which can only be > successful if the code has been greatly simplified beforehand > > Looking at these criteria and adding my own limited availability, I > decided that: > > 1. the current 2.2 code will be maintained frozen, with only bug fixes > and necessary adaptations, e.g. due to newer versions of Python. No > change will be done if it isn't requested by an user or package > maintainer through an issue. > 2. I'll start to work on the 3.x version, doing whatever is necessary to > reach my above objectives without considerations for backward API > compatibility. I still plan to have continuously working versions with > CI/CD pipeline etc, and it will be an evolution more than a revolution. > There should be a tool to migrate old repositories to a potential new > format, but it's not a promise (this said, I plan to keep similar > concepts, so there shouldn't be any reason for not having such a tool). > > I'm not yet 100% decided but I think 2.x will become a branch and the > 3.x development will simply happen on the master branch, where most > activity will be visible (not that people and/or statistiscs start to > think that rdiff-backup is dead or so). I also have the idea to have > weekly releases so that people can more simply try new features. > > If someone wants to volunteer to maintain the 2.x branch, I'd be more > than happy to help him/her onboard on this important task. I don't want > to put pressure on myself or anybody, but it probably would be an > endeavor for 2-3 years based on my past speed. > > Feel free to comment, but my decision is pretty much taken, for the > reasons listed above. > > KR, Eric > > -- *ATTENTION: Je serai en vacance du 6 Mai au 21 Mai 2023.* *ATTENTION: I will be on vacation from May 6 to May 21, 2023.* IKUS Software https://www.ikus-soft.com/ 514-971-6442 St-Colomban, QC J5K 1T9
