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
Received on 2019-06-24 16:24:57 CEST