Open Stack

Ttx wrote:
 > I think that suggestion is worth exploring in a separate thread. I don't
think it's really an alternative solution to the "life after EOL"
discussion, but it could be a complementary solution.
 >
 > One thing to realize here is that skip-release upgrades are a much
better way to deal with upgrade pain than extending cycles. If you
release every year instead of every 6 months, you get more changes in a
given release, and the upgrade becomes more painful. We should really be
releasing as often as we can, while making sure that upgrades are less
painful and that versions can be skipped.
 >
 > It's also not a great way to get longer-supported branches. Yes, that 
means branches get EOLed after two years rather than one. And yet a lot
of operators would like some branches to be supported for longer than
two years. What's the solution then ? Release every 18 or 24 months ? I
think the proposal for "life after EOL" being discussed in the other
thread is a better way to deal with that.

I agree strongly that longer release cycles are a bad thing (in general) 
and specifically won't get us closer to LTS releases. LTS releases are 
mostly a matter of investing in the manpower to keep very old stuff 
still working (not a fun job, but essential) and implementing better 
upgrade mechanisms.

Personally, I'd be in favor of shorter releases. IMO, 2 month release 
cycles are doable, although 3 or 4 month cycles might be a better goal 
to aim for. If the Linux kernel can do it, we can to. For all of the 
reasons ttx mentioned, long releases breed bad habits, and shorter 
releases tend to breed good habits. It's much less painful to "miss a 
release" when the next release is 2 months away, so new features can be 
given the review and testing they need instead of encouraging teams to 
take a gamble a merge features just because nobody wants to wait 6 or 
more months for the feature to land.

-Ben Swartzlander