On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman <hartman.nathan_at_gmail.com>
wrote:
> 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.
>
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.
Cheers,
-g
Received on 2019-06-30 10:47:34 CEST