Re: What comes after 1.12?

On Wed, Aug 21, 2019 at 6:47 AM Stefan Sperling wrote: > On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote: > > In my specific scenario with Subclipse things are just hard and I do not > > think anything can be done to help. Since the native libraries for the > API > > we need lives

Re: What comes after 1.12?

On Tue, Aug 20, 2019 at 7:04 PM Branko Čibej wrote: > 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

Re: What comes after 1.12?

On Tue, Aug 20, 2019 at 01:13:58PM -0400, Mark Phippard wrote: > In my specific scenario with Subclipse things are just hard and I do not > think anything can be done to help. Since the native libraries for the API > we need lives outside of our control we always have a problem of the > version to

Re: What comes after 1.12?

Julian Foad wrote: It looks like we need to make this clearer. Thank you for those suggestions. I will make some changes. Changed: http://subversion.apache.org/download http://svn.apache.org/r1865613 * download.html Add a notice of latest LTS release after notice of latest regular release.

Re: What comes after 1.12?

Thomas Singer wrote: What are the LTS releases? See https://subversion.apache.org/roadmap.html#release-planning Is this somehow detectable by a user from the name? Ubuntu, for example, adds "LTS" to the name of their releases, e.g. "18.04 LTS". Maybe at

Re: What comes after 1.12?

What are the LTS releases? Is this somehow detectable by a user from the name? Ubuntu, for example, adds "LTS" to the name of their releases, e.g. "18.04 LTS". Maybe at the title "Other Supported Release(s)" should rather be

Re: What comes after 1.12?

Thomas Singer wrote: >> 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 But... we are doing releases on a 24-month schedule. We are calling those "LTS" releases. They

Re: What comes after 1.12?

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

Re: What comes after 1.12?

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

Re: What comes after 1.12?

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

Re: What comes after 1.12?

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

Re: What comes after 1.12?

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

Re: What comes after 1.12?

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 >

Re: What comes after 1.12?

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