On 28.11.2017 23:25, Stefan wrote:
> 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.).
Oh, I'm not against the idea of having more regular releases and the
rest of the points in the proposal. Just pointing out things we'll want
to be aware of. (And hinting to RM volunteers to get their act together,
heh heh.)
> But of course having the multi-WC-version-support in 1.11 would mitigate
> this concern altogether. :-)
I started working on that, then (predictably) ran out of time ... the
starting point is on the better-pristines branch. I have every intention
of taking that up as soon as I have some free time, famous last words.
In the meantime, it appears that 1.8, 1.9 and 1.10 will all use the same
WC format (Julian? I hope stashes don't shatter that dream). So we're
pretty well covered in that respect. For now.
-- Brane
Received on 2017-11-28 23:37:49 CET