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?
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). So
even in the case where we'd raise the WC format in each build, I don't
quite see the implications this would have in the decision for or
against time-based releases.
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.
Example: VisualSVN decides that a 6-month release update is too much for
them and therefore only release LTS-based releases. This would then
prevent TSVN users from upgrading to TSVN versions other than the
LTS-release. If TSVN however would decide not to support LTS-releases
and only always release the latest version, then we'd be kind of screwed.
To clarify: I'm not arguing against moving to time-based releases. I'm
just not sure whether the 6-month period won't be too short in our case
and we'd better be off with a 9-12 period.
Received on 2017-11-28 20:23:30 CET