Release 2.12 - 3.0

John Marino dragonflybsd at marino.st
Tue Oct 18 22:42:32 PDT 2011


On 10/19/2011 5:05 AM, Justin Sherrill wrote:
This is where I saw "I TOLD you so!" and quietly stare at everyone 
with a smug look, cause I had proposed yearly release cycles just last 
month.  Please don't smack me for it.
I agree with Sascha that the cycle period is a separate topic, and 
having a one year cycle wouldn't have prevented this situation from 
occurring.  That said, regardless if the final solution is to delay the 
release (which sounds likely) I strongly believe we should stick to a 
six-month release cycle.  We might have to add extra time to the next 
one just to get it back to the times of the year we like  (April / 
October ?)

Having a nifty new software version with potential bugs is not unique 
to our software project.  Let's do what other projects do: say "Here's 
the new version.  It's in beta.  It has a lot of new features, but may 
have new bugs.  Please test".  That way we're not releasing with a 
known nasty bug, but we're not shutting off access to an already 
wildly improved next release.

Yeah, I don't like the way that came out.  Most people view companies 
that abuse the "beta" label negatively, and we definitely don't want to 
follow suit there.  Every software "may" have new bugs, the difference 
is when projects release it anyway or not.  We should only release when 
all known bugs are reasonably addressed.  The "it's in beta" rubs me the 
wrong way.  I get the idea that's the new Ubuntu approach and people are 
turned off by the reduced quality control that follows a beta mentality.

so my vote:
I don't mind exceptionally delaying a release three months to get a 
worthwhile patch set in comfortably, but I want to treat it as an 
exception and try to stick to 6 month periods.

John





More information about the Kernel mailing list