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

Intentions for 1.11 release timing

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 18 May 2018 14:49:47 +0200

On Fri, May 18, 2018 at 9:46 AM, Stefan Sperling <stsp_at_elego.de> wrote:

[ snip discussion about bumping the minimum JDK requirements ... (was
Re: JDK 10 removal of javah)]

> ... when
> Subversion 1.11 will be released in probably 2 to 3 years from now?

I think we need to aim for a much sooner 1.11 release. And I'd like us
to agree on some intended planning / timing. I know it's easy to talk
about it, and much more difficult to actually *do it*. But first
things first, what are our intentions?

During the Aachen 2017 hackathon we agreed we wanted to go towards
(more frequent) time-based releases. This was then discussed on list,
and there seemed to be consensus about it:

https://svn.haxx.se/dev/archive-2017-12/0004.shtml

Quoting:
> Great! I gather from the reactions in this thread that we have
> consensus on the principle, we "just" need to do it :-). And figure
> out some details.
>
> - WC multiple format support: we're okay for now (1.8 - 1.10 have the
> same format), but for 1.11 it would be good if we can make
> better-pristines happen (go Brane! :-).
>
> - Frequency: should we aim for 6 months, or 9, 12, ... for the "fast
> releases" (and "long term support" releases, each a couple of years
> apart)? I'd stick with my initial proposal: 6 month release cycle, and
> designate one as an LTS release every 2 years, of which we support one
> fully, and one more with only security fixes.

So, IMHO, we just need to pick a date for creating the 1.11.x branch
(the rest of the timing follows from that), and have some poor soul
volunteer to RM it :-).

(oh, and figure out those two minor details mentioned above ;-)

-- 
Johan
Received on 2018-05-18 14:50:13 CEST

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.