[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 2.0

From: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Tue, 25 Jun 2019 19:17:54 -0400

>
> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej <brane_at_apache.org> wrote:
>On 25.06.2019 19:16, Thomas Singer wrote:
>>> 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.
>>
>> I disagree. It is quite common use to name something 2.0 if it has
>> serious improvements over 1.x.
>
>That's marketing, not software development. :)

Subversion needs some marketing -- separately from and in addition to plans
for a 2.0.

I understand that from a technical perspective, there is no reason to
change the major version number unless compatibility/API/ABI promises are
going to be broken. A 2.0 means you can break those promises, BUT I propose
that just because you CAN do something doesn't mean you have to. Subversion
2.0 could very well keep 100% of 1.x's promises. Even though the option to
break promises exists, I would err on the side of keeping them anyway,
unless doing so (very sparingly) would provide compelling benefits that
outweigh the hassle caused by such breakage.

So why 2.0 then?

(1) To separate between a stable 1.x that focuses on keeping a clean issue
tracker and a 2.0 that focuses on new and experimental development. This
might give more freedom to experiment while reducing risk of disruption to
existing customers until new features are release-quality.

(2) To make it clear, in light of 1.x "going stable," that the project
won't turn away new development or new developers. Both are encouraged and
invited with open arms, always.

(3) Marketing.

Just to make this clear, I do not think it's a good idea to reimplement
Subversion in another language and I do not think the nature of Subversion
should be changed drastically. That would be a different product. I'm in
favor of longevity: Longevity of the project, longevity of keeping
promises, backward/forward compatibility between server/client and on-disk
data structures, etc. The fact that a dump and load has NOT been needed in
many years, the fact that Subversion is careful about preserving your
history -- in short, Longevity, should be a bragging point of Subversion.

Somewhere you said that it took 4 years to get from nothing to 1.0. The
difference between today and back then is that today you have a rock solid,
reliable, excellent 1.x; back then you had CVS. There's no rush to release
2.0, or even write code for it. The journey of 1000 miles doesn't begin
with a single step; it begins with deciding where to go. :-)
Received on 2019-06-26 01:18:10 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.