On 13.09.2018 14:13, Julian Foad wrote:
The 1.11.0-rc1 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.
Thanks!
Since I don't know if & when I will find time to address th
Daniel Shahaf wrote:
> From subversion/svn/info-cmd.c:
>272 if (TRUE)
>274 /* svn-viewspec.py format */
>281 else
>283 /* svn command-line format */
>
> Why is there an «if (TRUE)» there? Should that condition be exposed a
> command-line
>From subversion/svn/info-cmd.c:
246 cl_layout_list(apr_array_header_t *targets,
⋮
272if (TRUE)
273 {
274/* svn-viewspec.py format */
275llb.vs_py_format = 2;
276
277SVN_ERR(svn_client_layout_list(list_abspath,
278
Julian Foad wrote on Mon, 17 Sep 2018 15:47 +0100:
> Daniel Shahaf wrote:
> > [...] I suspect it won't be uncommon for an svn_x_foo() to be graduated
> > to a stable svn_foo() with little or no incompatible changes to its
> > signature and semantics. In such cases, could we keep the svn_x_*()
> >
In order to strike a balance between:
* Developing new features across the more frequent release
schedule
* Allowing developers to offer these features early, and users to
opt in to them
* Avoiding bricking a program as described by Daniel (program
fails to start after DLLs are upgraded)
Daniel Shahaf wrote:
> [...] I suspect it won't be uncommon for an svn_x_foo() to be graduated
> to a stable svn_foo() with little or no incompatible changes to its
> signature and semantics. In such cases, could we keep the svn_x_*()
> name around for one minor release cycle, with a warning, in o
Julian Foad wrote on Mon, 17 Sep 2018 12:36 +0100:
> Branko Čibej wrote:
> > Consequently, releasing experimental features to the stable set implies
> > removing [the experimental API] — and yes, this *will* create ABI
> > incompatibilities. If we decide that we cannot allow that and that ABI
> > c
Branko Čibej wrote on Mon, 17 Sep 2018 12:57 +0200:
> A corollary of the above is that we should never have aliases for
> experimental bits in another namespace: for example, if there is an 'svn
> x-shelve' command it should not have an 'svn shelve' alias, since that
> could lead users to believe t
Julian Foad wrote:
> [...] The users have no idea about that unless
> the developer takes care to tell them, [...]
A further point. As a library supplier, our responsibility for APIs is *only*
to the downstream developer. If that developer chooses to use our experimental
APIs to build a product
Branko Čibej wrote:
> The proposal to put experimental APIs (and command-line features) into a
> separate namespace is a variant of this off-by-default approach. [...]
> we can't exclude the experimental bits from the ABI [...]. Instead, we force
> downstream developers and users to consciously cho
On 16.09.2018 22:24, Julian Foad wrote:
> In this thread we have a lot of suggestions and disagreements. I started
> looking for existing practices that we could copy, and here is the first
> thing I found. The top three hits in a DuckDuckGo search for "experimental
> APIs" [1] have in common th
11 matches
Mail list logo
