On 20.08.2019 17:46, Julian Foad wrote:
> Julian Foad wrote:
>> [...] OR
>>
>> * Each version can add APIs but cannot remove or break existing
>> APIs? (Like our current rules for minor releases.)
>
> Reading back what I've just written, it seems I'm completely missing
> something. If we take
On Tue, Aug 20, 2019 at 3:06 PM Branko Čibej wrote:
> On 20.08.2019 20:50, Paul Hammant wrote:
> > If you all developed on trunk (patchsets for trunk, or direct to it),
> > and had an automated CI build setup that tested all permutations in
> > parallel, and a merging bot that attempted to
On 20.08.2019 20:50, Paul Hammant wrote:
> My DevOps consulting life (around how to get to Trunk-Based
> Development from some often ClearCase inspired branching model),
> starts with what release cadence are you at now, and what do you want
> to get to. Clients who are quartly want to get to
My DevOps consulting life (around how to get to Trunk-Based Development
from some often ClearCase inspired branching model), starts with what
release cadence are you at now, and what do you want to get to. Clients
who are quartly want to get to monthly (and have less unplanned releases
following
kot...@apache.org wrote on Tue, 20 Aug 2019 09:18 +00:00:
> When compiling SQLite, set the SQLITE_DEFAULT_MEMSTATUS=0 compile-time option.
>
> This is the recommended option that is not enabled by default. Setting it to
> zero avoids using a mutex (and thus suffering a performance penalty) during
kot...@apache.org wrote on Tue, 20 Aug 2019 09:23 +00:00:
> +++ subversion/trunk/subversion/libsvn_subr/sqlite3wrapper.c Tue Aug 20
> 09:23:55 2019
> @@ -26,6 +26,7 @@
> #ifdef SVN_SQLITE_INLINE
> # define SQLITE_OMIT_DEPRECATED 1
> # define SQLITE_DEFAULT_MEMSTATUS 0
> +# define
Probably the thing that would help me the most would be if
the releases slowed down. If we want them on a schedule then do it every 12
months instead of 6.
+1
--
Thomas
On Tue, Aug 20, 2019 at 11:46 AM Julian Foad wrote:
> Julian Foad wrote:
> > [...] OR
> >
> >* Each version can add APIs but cannot remove or break existing APIs?
> > (Like our current rules for minor releases.)
>
> Reading back what I've just written, it seems I'm completely missing
>
Julian Foad wrote:
[...] OR
* Each version can add APIs but cannot remove or break existing APIs?
(Like our current rules for minor releases.)
Reading back what I've just written, it seems I'm completely missing
something. If we take that approach (API changes allowed), then
everything
I'm going to quote a big chunk of what Mark wrote.
Mark Phippard wrote in "Subversion's community health":
[...] I feel like the current release
policy is the only realistic way to encourage contributions to the
product because there are known and predictable release vehicles to
deliver
10 matches
Mail list logo