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

Re: Subversion 1.10 RC1?

From: Branko Čibej <brane_at_apache.org>
Date: Wed, 22 Nov 2017 12:17:44 +0100

On 22.11.2017 11:53, Julian Foad wrote:
> At the hackathon today we (me, Stefan Hett, Bert, Johan) have been
> talking about how to progress 1.10.
>
> We think all the features and changes are safe to release and are not
> going to get more testing until we produce a "release candidate". (For
> example, at that point Stefan will be able to justify taking time at
> his work to test the client in production scenarios.)
>
>   * conflict resolution: we understand it is already much better than
> 1.9; low risk if parts of it don't work quite right; designed so that
> improvements can be made in patch releases.

Other than the new compiler warnings that keep popping up on trunk
related to the conflict resolution, I have no objections.

>   * LZ4 compression: in some senses the risk of bugs here is higher,
> but it seems like it is high quality already; is there one remaining
> place where we should add LZ4 negotiation (one direction of svnserve
> protocol)?

Would be nice to have LZ4 negotiation everywhere but not a blocker.

>   * shelving v1: is isolated -- doesn't affect anything else; is
> limited but already useful; will be changed in the next release so
> APIs are marked "SVN_EXPERIMENTAL"; changes shelved by this release
> could be detected and 'upgraded' by a future release; should the CLI
> commands be marked "experimental" in the help, too (Johan thinks yes)?

Unless you're absolutely certain that the format and semantics of the
CLI commands won't change, I do suggest adding an "experimental" warning
to the help text.

> After any issues raised in this discussion are resolved, we feel we
> should go ahead and produce RC1 as soon as possible.

+(1 − ε)

-- Brane
Received on 2017-11-22 12:17:50 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.