On 28/11/2017 22:34, Branko Čibej wrote:
> 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
>
Thanks for taking the time to explain your point. :-)
I still think that these type of products/tools will very likely stick
with the LTS version of SVN and/or provide LTS versions themselves. So
for them, I take it almost nothing would change for the time being.
Certainly they will take exactly the point you made into consideration
and hence are likely to conclude too this is one of the biggest
arguments for them to only provide LTS-based releases.
The aim as far as the talks during the hackathon went suggested that we
primarily target the "casual" user like you and me as the target
audience for the releases available at shorter intervals. I guess the
advantages of the shorter interval are quite obvious and aren't really
in question here (just to give some headlines here: better/faster test
coverage of new versions; faster iterations of new features; self-set
deadlines for integrations; etc.).
But of course having the multi-WC-version-support in 1.11 would mitigate
this concern altogether. :-)
Regards,
Stefan
Received on 2017-11-28 23:25:57 CET