On Tue, Feb 8, 2011 at 11:37 AM, Robert Newson <robert.new...@gmail.com> wrote:
> You're absolutely right. 1.0.2 was ready to go quite some time ago but
> several bugs were found as we were releasing. We decided, as a team,
> that we couldn't ship with the bugs that were found, so we elected to
> fix them and delay the release. I think that was the right decision.
> We should only release when we feel the software is ready, not when
> some ultimately arbitrary day looms.

I completely agree here: there should be no arbitrary release dates.
However, I'm also in favor of increasing the frequency of minor point
releases. Node.js is really inspiring in this area, with new minor
point releases coming out every week or so (ooh, and 0.4.0 just got
released 6 hours ago!). I know the process for an Apache project has
more overhead, we don't have a BDFL, and the older community may not
appreciate a release cycle that's quite so frantic (interpret that as
you like), but there's still something to be learned from the rapid
development and enthusiastic community around Node.

> B.
>
> On Tue, Feb 8, 2011 at 4:32 PM, Noah Slater <nsla...@apache.org> wrote:
>>
>> On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote:
>>
>>> Still, the problem I have is that it seems like there is a tendency to
>>> make releases large; it seems like there's little control against devs
>>> wanting to add their "one more thing". Particularly for bugfix
>>> releases; from 1.0.1 it took almost 6 months for 1.0.2 to get
>>> released. In between, there were a little under 100 revisions on the
>>> 1.0.x branch, presumably most of those fixing bugs users could
>>> actually run into. It seems valuable to me if the community could have
>>> gotten some of these fixes sooner.
>>
>> I need someone else to weigh in on this, but I believe the reason was 
>> because of a few critical bugs that were being worked on. And not, as you 
>> suggest, because we were suffering from a Just One More Thing problem. I'd 
>> really need Jan or Chris to comment though as I use them as a conduit for 
>> judging this stuff.
>

Reply via email to