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

Re: Let's switch to time-based releases

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 28 Nov 2017 22:34:49 +0100

On 28.11.2017 20:23, Stefan wrote:
> On 28/11/2017 16:16, Branko Čibej wrote:
>> On 28.11.2017 15:01, Stefan wrote:
>>> I'm also a bit worried about the acceptance of faster releases (i.e.
>>> once every 6 months). Maybe we'd simply send out a mail to maintainers
>>> polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
>>> new releases)? Just for us to get some idea on what those people who'd
>>> be directly impacted by our decision would think about before we are
>>> making a call?
>> That depends a lot on how we handle client (working copy!) compatibility
>> in future. Breaking the WC every 6 months is not acceptable; people will
>> simply not adopt newer versions of the client if we do that.
>>
>> -- Brane
> Are you referring to breaking the possibility for users to go back to
> older clients, if they run into problems with newer versions and their
> WC having already been upgraded? If so, personally I won't see this as a
> strong concern. Or am I missing your point?

This is exactly the point. People have to use different tools that
support different SVN client versions. Every time we break WC
compatibility we make life hell for users who cannot upgrade all their
(development and other) tools for one reason or another. This is not an
imaginary problem, we've heard lots of complaints over the years about that.

> But even if so, for users it's completely up to them to decide whether
> they want to upgrade to a later version (or skip one or the other).

No, it's not. "Users" are not just people like you and me who use the
command-line client, maybe TSVN, vc-svn.el in Emacs etc. They're also
people who use custom integrated toolsets from multiple vendors who, you
can bet, will not change their release time-line just because one small
part of their solution could be upgraded.

> I'm more concerned about the case where users rely on more than a single
> client to work with (for example a common combination on Windows would
> be TSVN+VisualSVN) and these products would use different release cycles.

TSVN and VisualSVN are *trivial* examples. I'm talking about toolsets
where version control is maybe 5% of the functionality, or not even that.

The solution, of course, is to support multiple WC versions in the
client. :)

-- Brane
Received on 2017-11-28 22:34:56 CET

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