On Thu, 2011-01-20 at 21:14 +, Stephen Connolly wrote:
> so to be clear, april 9th is feature complete for 0.8.0 and then start
> stabilisation...
Yes
> ...and when might we see a 0.7.1
Before then. Well before. Soon.
--
Eric Evans
eev...@rackspace.com
so to be clear, april 9th is feature complete for 0.8.0 and then start
stabilisation... and when might we see a 0.7.1
or am I completely confused?
...
trying to plan splitting the jar into parts, and delivering ever build
tweaks for allowing abny dev to push release to central repository ;-)
-
On Thu, 2011-01-20 at 10:19 -0800, Ryan King wrote:
> On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans wrote:
> > On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
> >> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans wrote:
> >> > The discussion seems to be petering out and I wonder if that means
On Thu, 2011-01-20 at 10:19 -0800, Ryan King wrote:
> 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
On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans wrote:
> On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
>> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans wrote:
>> > The discussion seems to be petering out and I wonder if that means folks
>> > are still trying to wrap their heads around every
On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans 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 a
On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans 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
> branche
On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote:
> > Everyone on chrome commits to trunk first. I think the important
> > change we could make is to keep everyone closer to trunk. We spend a
> > good deal of effort back-porting patches between major versions. I
> > think we should make the majo
On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote:
> On Thu, 2011-01-13 at 14:32 -0800, Ryan King wrote:
> > # Fixed schedule
> >
> > We should set a fixed schedule and stick to it. Anything features not
> > ready at branch time won't make it and will be disabled in the stable
> > branch.
>
> I
On Thu, 2011-01-13 at 14:32 -0800, Ryan King wrote:
> # Fixed schedule
>
> We should set a fixed schedule and stick to it. Anything features not
> ready at branch time won't make it and will be disabled in the stable
> branch.
In general, I agree, if we want a cadence, we're going to have to exer
On Thu, Jan 13, 2011 at 4:04 PM, Jonathan Ellis wrote:
> On Thu, Jan 13, 2011 at 2:32 PM, Ryan King wrote:
>> # Fixed schedule
>>
>> We should set a fixed schedule and stick to it. Anything features not
>> ready at branch time won't make it and will be disabled in the stable
>> branch.
>
> I like
On Thu, Jan 13, 2011 at 2:32 PM, Ryan King wrote:
> # Fixed schedule
>
> We should set a fixed schedule and stick to it. Anything features not
> ready at branch time won't make it and will be disabled in the stable
> branch.
I like this idea, as long as we're willing to be flexible when
warranted
To be more clear, here's what I think is broken in the current release planning:
1. The dates are wildly unpredictable
2. People aren't allowed to work against trunk on features for
multiple iterations (see #1072)
3. Stable branches diverge too much, causing duplicated effort. (we
essentially impl
I think many believe that shipping 0.7 took longer than it should.
Rather than going into why that happened, I'd like to propose a better
way to move forward that will hopefully allow us to ship on a more
predictable schedule. This proposal is heavily influenced by the
google chrome release process
14 matches
Mail list logo
