Intentions for 1.11 release timing

[Johan Corveleyn <jc...@gmail.com>]

On Fri, May 18, 2018 at 9:46 AM, Stefan Sperling <st...@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

Re: Intentions for 1.11 release timing

[Daniel Shahaf <d....@daniel.shahaf.name>]

Julian Foad wrote on Fri, 18 May 2018 14:54 +0100:
> standard release:
>   * full backports at least until the next standard release
>   * security/corruption fixes at least until the next-but-one standard release

Nitpick, but: s/until the next standard release/until the next release/
(whether the next release is standard or LTS)

Re: Intentions for 1.11 release timing

[Stefan Hett <st...@egosoft.com>]

On 5/18/2018 4:27 PM, Julian Foad wrote:
> Stefan Sperling wrote on 2018-05-18:
>> On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote:
>>> LTS release:
>>>    * full backports for at least 2 years, and at least until the next LTS release
>>>    * security/corruption fixes for at least 4 years, and at least until the next-but-one LTS release
>> What do you mean exactly with next-but-one LTS release?
> I meant:
>    * full backports for the greater of (until the (N+1)th LTS release) and (2 years)
>    * security/corruption fixes for the greater of (until the (N+2)th LTS release) and (4 years)
>
> So if someone ignores all the non-LTS releases from now on, the promises they get for LTS releases would correspond pretty much exactly to how we have been managing all of our release up to and including 1.10.
>
> BTW, as well as designating 1.10 as LTS, we would also designate 1.9 as an LTS release (which is now in its "security/corruption fixes only" support phase). And the way we are treating 1.8 (which recently reached the end of its security/corruption fixes support period) would be exactly the same as if we had designated 1.8 as an LTS release.
>
> - Julian
>
FWIW: Sounds all fine and in line with what was discussed/agreed upon 
already. Personally I still have the feeling that moving on to the 6 
month release cycle might turn out to be quite a release burdon/overhead 
but that already was said that we eventually might have to adjust the 
release procedure a bit and improve the automation (which already 
improved for the 1.10 release).

-- 
Regards,
Stefan Hett

Re: Intentions for 1.11 release timing

[Julian Foad <ju...@apache.org>]

Stefan Sperling wrote on 2018-05-18:
> On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote:
> > LTS release:
> >   * full backports for at least 2 years, and at least until the next LTS release
> >   * security/corruption fixes for at least 4 years, and at least until the next-but-one LTS release
> 
> What do you mean exactly with next-but-one LTS release?

I meant:
  * full backports for the greater of (until the (N+1)th LTS release) and (2 years)
  * security/corruption fixes for the greater of (until the (N+2)th LTS release) and (4 years)

So if someone ignores all the non-LTS releases from now on, the promises they get for LTS releases would correspond pretty much exactly to how we have been managing all of our release up to and including 1.10.

BTW, as well as designating 1.10 as LTS, we would also designate 1.9 as an LTS release (which is now in its "security/corruption fixes only" support phase). And the way we are treating 1.8 (which recently reached the end of its security/corruption fixes support period) would be exactly the same as if we had designated 1.8 as an LTS release.

- Julian

Re: Intentions for 1.11 release timing

[Stefan Sperling <st...@elego.de>]

On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> > > Branch for stabilization 4 months after the last release (which was in 2018-04), so:
> > > 
> > >   * Branch in 2018-08
> > >   * Aim to release in 2018-10
> > 
> > Wouldn't we also have to adjust our backporting guidelines if we
> > did this?
> 
> Yes, certainly we have to adjust our backporting guidelines!
> 
> > Would 1.10 only receive "security or data corruption
> > fixes" as of October 2018?
> 
> No, 1.10 would be designated "LTS" (long term support).
> 
> Because we haven't previously told users anything, they should assume
> that 1.10 will be supported over a similar time scale to previous
> releases. Therefore we should designate 1.10 as LTS, and 1.11 as a
> standard (non-LTS) release.

Ok, I see. Yes, that makes a lot of sense :)

> LTS release:
>   * full backports for at least 2 years, and at least until the next LTS release
>   * security/corruption fixes for at least 4 years, and at least until the next-but-one LTS release

What do you mean exactly with next-but-one LTS release?
Do you intend to have two offer LTS releases in parallel?
Or will there only ever be one LTS release at a time (I would prefer this)?

Don't you think 6 years in total lifetime for an LTS is a bit much?

The wording "at least 4 years" combined with "at least until next LTS"
is a bit confusing. Which of these guidelines takes precedence?
Did you intend to write "at most" for one or both of these guidelines?

> standard release:
>   * full backports at least until the next standard release
>   * security/corruption fixes at least until the next-but-one standard release
> 
> Plus a bit extra (e.g. a couple of months) on each of these times.

I think many of our users would appreciate such a scheme since it
provides a mix of new features vs long-term stability.

Re: Intentions for 1.11 release timing

[Julian Foad <ju...@apache.org>]

Stefan Sperling wrote:
> On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> > Branch for stabilization 4 months after the last release (which was in 2018-04), so:
> > 
> >   * Branch in 2018-08
> >   * Aim to release in 2018-10
> 
> Wouldn't we also have to adjust our backporting guidelines if we
> did this?

Yes, certainly we have to adjust our backporting guidelines!

> Would 1.10 only receive "security or data corruption
> fixes" as of October 2018?

No, 1.10 would be designated "LTS" (long term support).

Because we haven't previously told users anything, they should assume that 1.10 will be supported over a similar time scale to previous releases. Therefore we should designate 1.10 as LTS, and 1.11 as a standard (non-LTS) release.

Definitions something like this:

LTS release:
  * full backports for at least 2 years, and at least until the next LTS release
  * security/corruption fixes for at least 4 years, and at least until the next-but-one LTS release

standard release:
  * full backports at least until the next standard release
  * security/corruption fixes at least until the next-but-one standard release

Plus a bit extra (e.g. a couple of months) on each of these times.

- Julian

Re: Intentions for 1.11 release timing

[Stefan Sperling <st...@elego.de>]

On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> Branch for stabilization 4 months after the last release (which was in 2018-04), so:
> 
>   * Branch in 2018-08
>   * Aim to release in 2018-10

Wouldn't we also have to adjust our backporting guidelines if we
did this? Would 1.10 only receive "security or data corruption
fixes" as of October 2018?

My impression is that many of our users today are companies which
are not in a hurry at all about upgrading their infrastructure.
The kind of feedback we have been getting for 1.10.0 reflects this.
A lot of it seems to be from QA folks who are testing 1.10.0 before
it gets a wider rollout in their organization. In October, these
people will just about have finally deployed 1.10 on a wider scale.

I don't have a problem with moving to a faster cycle myself.
I'll note though that this has already been attempted in the
past, even when we had a lot more development activity in the
project, and it never worked because in the end our own quality
assurance requirements took precedence over a quick release cycle.

Re: Intentions for 1.11 release timing

[Julian Foad <ju...@apache.org>]

Johan Corveleyn wrote:
> 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?

Yes, let's agree a plan. Thanks for raising this.

The suggestion below for a 6-month "fast" cycle with 2-year "LTS" releases is in line with what I think we should be doing and what I think we *can* do. On top of that, it is similar to what some other stable software projects do (I'm thinking of Ubuntu).

So I support that plan.

I don't recall any objections outstanding. Yes, of course it will be more difficult initially, and yes, we don't have much capacity, but the idea is that the new plan will improve the situation.

Some details need "fleshing out" (such as what we do if the schedule slips considerably), but that is fine, we can decide those details after the main decision.

> > - 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! :-).

It would be good, yes, but not a blocker. We can continue without it for the time being. If and when we want or need a format bump, we can figure out what to do at that point.

> > - 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.

+1.

> 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 :-).

Branch for stabilization 4 months after the last release (which was in 2018-04), so:

  * Branch in 2018-08
  * Aim to release in 2018-10

(I choose the 1.10 release date rather than branching date as a baseline, because we had much more and much older changes that needed testing, reviewing and fixing. In a 6-month cycle we should be able to stabilize more quickly.)

At this time, I know of no reason why I would not be able to RM 1.11 myself. Otherwise I am happy to lend some support to someone else doing it.

- Julian