DragonFly BSD
DragonFly kernel List (threaded) for 2011-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Release 2.12 - 3.0

From: John Marino <dragonflybsd@xxxxxxxxx>
Date: Wed, 19 Oct 2011 07:39:58 +0200

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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]