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. Regards, Stefan
