On Thu, 2011-01-20 at 10:19 -0800, Ryan King wrote:
> On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans <eev...@rackspace.com> wrote:
> > On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
> >> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans <eev...@rackspace.com> wrote:
> >> > The discussion seems to be petering out and I wonder if that means folks
> >> > are still trying to wrap their heads around everything, or if we have
> >> > consensus.
> >> >
> >> > If we're in agreement on 4 months between releases, and feature-freezing
> >> > branches in the run-up, then that would leave us with say 7 weeks (give
> >> > or take) to land everything in trunk that we expect in the next release
> >> > (and I would think that at this point we'd at least have a good idea
> >> > what that'd be).
> >>
> >> Sounds good.
> >>
> >> I've assigned to the Riptano/Datastax team the issues we can get to in
> >
> > OK, then I'm going to assume we have consensus on this.
> >
> > So again, we released on Jan 9th, 4 months (nominally) would give us a
> > release date of May 9th.  We need a few weeks for testing and bug
> > fixing, say time enough for a couple beta iterations, so let's set a
> > tentative date of April 9 to branch, (just under 7 weeks from now).
> >
> > As of right now I see 71 issues marked 0.8.  I haven't been through all
> > of them, some are trivial or have patches attached, but some are no
> > doubt unrealistic considering the time-line.
> >
> > For any issues you're championing, please take some time over the next
> > couple of weeks to make sure the ones marked fixfor-0.8 match what you
> > can accomplish before we branch.
> >
> > Is that reasonable to everyone?
> 
> Seems reasonable to me, though I think the release date can be a bit
> more flexible (while the freeze date shouldn't be). In other words, if
> we feature freeze and branch on April 9th, then we're ready to ship
> before May 9th, we should just go ahead and ship.

That time isn't just useful for fixing bugs, its for finding them too.

I'd say just let it settle and always release on the planned date. Spend
the extra time writing tests / running tests, fixing minor bugs, or
working on the next set of features for the next release. If you were
talking about releasing months early, that would be something.. but an
extra week of testing means a more stable release most likely, whereas
dropping the release early doesn't really help much.

Reply via email to