On 21.06.2019 13:12, Nathan Hartman wrote: > Subversion 1.x is mature, stable, rock-solid, reliable, and safe. The > goal of 1.x is now stability and availability. Big changes and > whiz-bang new features don't really belong there. It's time for > Subversion 2.0, the Subversion of the future.
I don't want to rain on anyone's parade but here's some food for thought. The only valid reason to call anything 2.0 is if, and only if, we decide to break backwards compatibility in some area. Now sure we can find more or less valid arguments to do that, but they have to be weighed very carefully indeed. Remember that there's almost 20 years worth of stable code and tests here; you don't throw that away without due consideration. We should also keep in mind the many, many existing servers and repositories. Any 2.0 will have to provide more than just an upgrade path, it will have to keep all those repositories functional for both 1.x and 2.x clients. Here are some *not* valid reasons for 2.0: 1. Rewrite Subversion in another language That's just not going to happen. Yes, we can write new code in Rust/Go/D/Scala/whatever, *if* we decide that the whole world is winux and *BSD and we don't care about legacy systems. But aiming to replace the codebase with something new is the surest way to kill the project that I can think of. We're not likely to attract new developers if we plan to get bogged down for years without a major new release (remember, it took us 4 years to get from nothing to 1.0). 2. "I don't like the way feature X is implemented, let's replace it with something better" I can certainly understand and even share that feeling. However: a) see above under "20 years of stable code", and b) there are always ways to make improvements in a backward-compatible way. As a user of software, the thing I hate the most is when people gratuitously break API/ABI/UI compatibility for no better reason than "it's better this way." 3. "This protocol is too chatty, let's invent a better one" Our wire protocol is a module. We can invent new ones without affecting existing ones. Likewise for repository storage, or working copy storage, etc. (with the latter actually being the hardest to change, due to hysterical ... um, I mean historical reasons). -- Brane
