On Sun, Jun 30, 2019 at 4:47 AM Greg Stein <gstein_at_gmail.com> wrote:
> On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman <hartman.nathan_at_gmail.com>
> wrote:
>
>> 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.
>>
>
> That isn't how it works.
>
> Subversion 1.x is a signal to system administrators that they can upgrade
> their 1.x installations to the latest 1.x and NOT WORRY.
>
> Once you bring in 2.x, regardless of what the developers do to keep/lose
> compatibility ... you have lost the 20-year guarantee of compatibility. The
> admin must now do some research. And the question in that admin's head will
> always be "what am I missing? if this is compatible with 1.x, and I should
> not fear upgrading to 2.0 ... then why did they change the version number?
> that was supposed to be a signal."
>
> For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes
> no guarantee". You speak of "marketing". There is no amount of marketing
> that will alter the past 20 years of our API guarantees.
>
>
That is actually perfect.
There are several challenges here that need to be addressed.
One is the need for more developer participation. Working on that...
Another is that one of Subversion's strengths is also a weakness. The
20 year guarantee is great for system administrators and users. It
demonstrates stability and reliability, which is important given what
Subversion does. This isn't a video game; this software houses your
precious data! Years and years of forward and backward compatibility is
a bragging point and a strength.
But it's also a weakness because it means that we can't be bold and
experiment, as that would break guarantees and bring instability.
So, okay, that's a legitimate explanation as to why we don't up the
version number to 2.0 unnecessarily. But I still think we need the
*concept* of a 2.0 as a way of moving forward. So I'll alter what I
said before, slightly: Bug fixes, stability improvements, and stable
production-ready features should go into 1.x, while 2.0 should be the
playground for bold experiments, developers, and adventurous users.
It doesn't matter if there's ever a 2.0 release. Instead, as features
in 2.0 become stable and production-ready, they can be merged back to
1.x and become part of the next "no worries" 1.x release, provided
they do not break compatibility! If they break compatibility, then
we'll cross that bridge when we get to it.
So, yes, 1.x can live on and on, until 1.414213562373095.
For marketing purposes, we could give names to releases that introduce
major new (but stable and production-ready) functionality.
The important thing is: We want devs! So we do not want to create an
impression that bold new stuff isn't welcome. It's welcome and it has
a place called 2.0!!
Received on 2019-06-30 17:36:25 CEST