> On 20 Apr 2018, at 01:39, Daniel Ruggeri <drugg...@primary.net> wrote: > > I'm not sure where in the conversation to add this, but I do want to > point out a mechanical concern. > > > If we end up with API and feature freeze on branch 2.4, then we'd expect > to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release > branch) can't get a feature or the next great thing because of a > required API incompatible change. We would then kick out 2.8, 2.10 and > so on and so forth. This seems like it would satisfy both the > keep-the-stuff-stable as well as the give-users-new-stuff "sides". > > > Mechanically, this can become tiresome for a volunteer as we work > through the STATUS ceremony for each of the branches. I remember that > being less than enjoyable when 2.0, 2.2 and 2.4 were all release > branches. I'm fearful of a future where we may have five branches and a > bugfix applicable to all (or worse... a security fix that would dictate > all should be released/disclosed at the same time).
Presumably most/all of that toil can be automated away as you have started doing, so that human intervention is only required where human judgement is actually required? Does httpd have some massive CD/CI pipeline in the background I don’t see or could it do with one? - Mark
