FAQ
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:

http://www.scribd.com/doc/46659928/Chrome-Release-Cycle-12-16-2010'

..which is heavily influenced by how large websites deploy code
(everyone close to trunk, hide incomplete changes behind configuration
flags, etc.)

I'm not saying we should adopt this process as-is, but some aspects of
it seem like they would be valuable–

# 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.

# Trunk-first

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 major versions less different. This would
mean letting them live for shorter amounts of time and possibly making
them bugfix only. Currently we add new features in stable branches,
but I think if we made the major release schedule more predictable
people would be more comfortable with letting their new feature wait
until the next major version.

We should be more liberal about committing things to trunk early and
iterating on them there (rather than iterating on them in patches). If
the features are unstable we can either hide them behind configuration
flags or remove them when we cut a stable branch.

# Automate all tests

I think the only way that we can keep people close to trunk and stay
stable is to build automated tests for *everything*. All code should
be exercised by thorough unit tests and distributed black-box tests.
Every regression should get a test.


Chrome has a 6 week cycle. I think ours would be more like 4 months
for major releases.

Whatever we do, I think the schedule needs to be more predictable,
which means that the contents of each release will be less predictable
(since its "whatever's ready at the appointed time"). Like the Chrome
presentation mentioned the idea isn't raw speed, but predictable
release schedules.

Feedback please.

-ryan

Search Discussions

  • Ryan King at Jan 13, 2011 at 10:50 pm
    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 implemented #1072 twice for 0.6 and 0.7)
    4, back porting features is risky and causes bugs, esp with the
    limited QA available

    -ryan
    On Thu, Jan 13, 2011 at 2:32 PM, Ryan King wrote:
    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:

    http://www.scribd.com/doc/46659928/Chrome-Release-Cycle-12-16-2010'

    ..which is heavily influenced by how large websites deploy code
    (everyone close to trunk, hide incomplete changes behind configuration
    flags, etc.)

    I'm not saying we should adopt this process as-is, but some aspects of
    it seem like they would be valuable–

    # 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.

    # Trunk-first

    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 major versions less different. This would
    mean letting them live for shorter amounts of time and possibly making
    them bugfix only. Currently we add new features in stable branches,
    but I think if we made the major release schedule more predictable
    people would be more comfortable with letting their new feature wait
    until the next major version.

    We should be more liberal about committing things to trunk early and
    iterating on them there (rather than iterating on them in patches). If
    the features are unstable we can either hide them behind configuration
    flags or remove them when we cut a stable branch.

    # Automate all tests

    I think the only way that we can keep people close to trunk and stay
    stable is to build automated tests for *everything*. All code should
    be exercised by thorough unit tests and distributed black-box tests.
    Every regression should get a test.


    Chrome has a 6 week cycle. I think ours would be more like 4 months
    for major releases.

    Whatever we do, I think the schedule needs to be more predictable,
    which means that the contents of each release will be less predictable
    (since its "whatever's ready at the appointed time"). Like the Chrome
    presentation mentioned the idea isn't raw speed, but predictable
    release schedules.

    Feedback please.

    -ryan
  • Jonathan Ellis at Jan 14, 2011 at 12:04 am

    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. Sometimes it is less work to finish a feature, than to rip
    it out.
    # Trunk-first

    Everyone on chrome commits to trunk first.
    I suppose that's fine if it works for them, but it's not The One True
    Way. Changes that affect both stable and trunk branches should really
    be applied to stable first and merged forward. Here is a good
    presentation explaining why:
    http://video.google.com/videoplay?docid=-577744660535947210.

    Another reason is that committing fixes to a stable branch and then
    using "svn merge branch" from trunk means svn tracks everything that
    has been committed to branch and not yet to trunk, and merges it in.
    So it protects us somewhat against people committing a fix to trunk,
    then forgetting to commit to the stable branch.
    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 major versions less different. This would
    mean letting them live for shorter amounts of time and possibly making
    them bugfix only.
    In theory I agree (see: policy for 0.4 and 0.5 stable releases). In
    practice, users overwhelmingly wanted more than that in between major
    releases. Not that users are always right, but this is an area where
    I think they are worth listening to. :)
    I think if we made the major release schedule more predictable
    people would be more comfortable with letting their new feature wait
    until the next major version.
    In my experience it's not the unpredictability as much as "I'm feeling
    this pain Right Now and four months is too long to wait."
    We should be more liberal about committing things to trunk early and
    iterating on them there (rather than iterating on them in patches).
    I agree in the sense that we were too slow to branch 0.7 to have an
    open trunk to start work on.

    But I disagree in the sense that we shouldn't be committing
    works-in-progress to trunk because that becomes the baseline everyone
    else has to develop from. (I know at least one team with a nontrivial
    patchset against trunk from the 0.7 beta1 timeframe, back when it had
    the Clock struct that we committed prematurely.)

    IMO the right fix is to help the ASF make git an option; in the
    meantime the best workaround is a git-based workflow with
    git-jira-attacher and git-am as described in
    http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
    and http://wiki.apache.org/cassandra/GitAndJIRA.
    # Automate all tests

    I think the only way that we can keep people close to trunk and stay
    stable is to build automated tests for *everything*. All code should
    be exercised by thorough unit tests and distributed black-box tests.
    Every regression should get a test. Agreed.
    Chrome has a 6 week cycle. I think ours would be more like 4 months
    for major releases.
    Four months feels about right to me, too, although for 0.7 + 1 I'd
    like to make it a bit shorter (beginning of April?) since we have
    several features (1072 being the most prominent) that just barely
    missed 0.7.
    Whatever we do, I think the schedule needs to be more predictable,
    which means that the contents of each release will be less predictable
    (since its "whatever's ready at the appointed time"). Like the Chrome
    presentation mentioned the idea isn't raw speed, but predictable
    release schedules.
    I agree. At the least, I think it's worth trying.

    --
    Jonathan Ellis
    Project Chair, Apache Cassandra
    co-founder of Riptano, the source for professional Cassandra support
    http://riptano.com
  • Ryan King at Jan 14, 2011 at 1:39 am

    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 this idea, as long as we're willing to be flexible when
    warranted.  Sometimes it is less work to finish a feature, than to rip
    it out.
    Two things:

    First, I think a key part of how you make this successful (both for
    Chome and for continuously deployed software like large services) is
    that non-trivial changes almost always have to be hidden behind flags
    until they're ready for wide use.

    Second, I think this will only work well if we are somewhat strict about it.
    # Trunk-first

    Everyone on chrome commits to trunk first.
    I suppose that's fine if it works for them, but it's not The One True
    Way.  Changes that affect both stable and trunk branches should really
    be applied to stable first and merged forward.  Here is a good
    presentation explaining why:
    http://video.google.com/videoplay?docid=-577744660535947210.

    Another reason is that committing fixes to a stable branch and then
    using "svn merge branch" from trunk means svn tracks everything that
    has been committed to branch and not yet to trunk, and merges it in.
    So it protects us somewhat against people committing a fix to trunk,
    then forgetting to commit to the stable branch.
    I guess I don't care as much about the mechanics of this as the
    intent– which is to keep stable and trunk closer together. And to keep
    people working on a more common base.
    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 major versions less different. This would
    mean letting them live for shorter amounts of time and possibly making
    them bugfix only.
    In theory I agree (see: policy for 0.4 and 0.5 stable releases).  In
    practice, users overwhelmingly wanted more than that in between major
    releases.  Not that users are always right, but this is an area where
    I think they are worth listening to. :)
    Perhaps minor things are worth adding in a stable branch. I think this
    is an area where judgement can come into play.
    I think if we made the major release schedule more predictable
    people would be more comfortable with letting their new feature wait
    until the next major version.
    In my experience it's not the unpredictability as much as "I'm feeling
    this pain Right Now and four months is too long to wait."
    Perhaps waiting is the biggest pain for users, but for developers
    unpredictability is just as big a problem. If I don't know when
    release N+1 is going to happen I might try to hurry to get my feature
    into release N. If I have confidence that release N+1 will come
    promptly at a scheduled time I can set my expectation appropriately.
    We should be more liberal about committing things to trunk early and
    iterating on them there (rather than iterating on them in patches).
    I agree in the sense that we were too slow to branch 0.7 to have an
    open trunk to start work on.

    But I disagree in the sense that we shouldn't be committing
    works-in-progress to trunk because that becomes the baseline everyone
    else has to develop from.  (I know at least one team with a nontrivial
    patchset against trunk from the 0.7 beta1 timeframe, back when it had
    the Clock struct that we committed prematurely.)
    So we made a mistake once. :) I think committing large changes in
    smaller pieces will be a net positive, even if it occasionally trips
    us up. For example, I think work on counters between our team and
    Sylvain has improved dramatically once we committed 1072.
    IMO the right fix is to help the ASF make git an option; in the
    meantime the best workaround is a git-based workflow with
    git-jira-attacher and git-am as described in
    http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
    and http://wiki.apache.org/cassandra/GitAndJIRA.
    So you're proposing that we use git to keep long-running feature branches?
    # Automate all tests

    I think the only way that we can keep people close to trunk and stay
    stable is to build automated tests for *everything*. All code should
    be exercised by thorough unit tests and distributed black-box tests.
    Every regression should get a test. Agreed.
    Chrome has a 6 week cycle. I think ours would be more like 4 months
    for major releases.
    Four months feels about right to me, too, although for 0.7 + 1 I'd
    like to make it a bit shorter (beginning of April?) since we have
    several features (1072 being the most prominent) that just barely
    missed 0.7.
    Like I said, we're going to have to figure out the right pace, but we
    should try and stick to it.
    Whatever we do, I think the schedule needs to be more predictable,
    which means that the contents of each release will be less predictable
    (since its "whatever's ready at the appointed time"). Like the Chrome
    presentation mentioned the idea isn't raw speed, but predictable
    release schedules.
    I agree.  At the least, I think it's worth trying.
    Good.

    -ryan
  • Eric Evans at Jan 14, 2011 at 7:09 pm

    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 exert
    some pressure to release at an agreed upon time. But, as Jonathan says,
    we need to be flexible.

    Even on this project, there have been times when we've put a clock on a
    stable release, and had problems with people rushing in poorly tested
    changes.
    # Trunk-first

    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 major versions less different. This would
    mean letting them live for shorter amounts of time and possibly making
    them bugfix only. Currently we add new features in stable branches,
    but I think if we made the major release schedule more predictable
    people would be more comfortable with letting their new feature wait
    until the next major version.
    I'll call your keep-close-to-trunk, and raise you a:

    * branch as soon as all planned features land in trunk
    * iteratively release betas w/ bug-fixes only
    * release candidates are actual candidates for the final (not releases)

    The time between creating the branch and making the release should be as
    short as practical, and there should be no backward incompatible changes
    between the first beta, and final release.
    We should be more liberal about committing things to trunk early and
    iterating on them there (rather than iterating on them in patches). If
    the features are unstable we can either hide them behind configuration
    flags or remove them when we cut a stable branch.
    As Jonathan said elsewhere in this thread, Git is finally within reach,
    and would solve many of the current technical limitations with our
    current process. I'd favor that as a first-step.
    # Automate all tests

    I think the only way that we can keep people close to trunk and stay
    stable is to build automated tests for *everything*. All code should
    be exercised by thorough unit tests and distributed black-box tests.
    Every regression should get a test.
    Absolutely.
    Chrome has a 6 week cycle. I think ours would be more like 4 months
    for major releases.

    Whatever we do, I think the schedule needs to be more predictable,
    which means that the contents of each release will be less predictable
    (since its "whatever's ready at the appointed time"). Like the Chrome
    presentation mentioned the idea isn't raw speed, but predictable
    release schedules.
    Yeah. Sounds good.

    --
    Eric Evans
    eevans@rackspace.com
  • Clint Byrum at Jan 17, 2011 at 3:55 am

    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.
    In general, I agree, if we want a cadence, we're going to have to exert
    some pressure to release at an agreed upon time. But, as Jonathan says,
    we need to be flexible.

    Even on this project, there have been times when we've put a clock on a
    stable release, and had problems with people rushing in poorly tested
    changes.
    The Ubuntu project has only slipped (to my knowledge) once in nearly 7
    years of 6 month cadence releases. The key is to respect feature
    freezes, and get everybody on board with slowing or even halting their
    feature work at those freezes to fix the bugs or even revert things that
    have panned out poorly.

    Currently Ubuntu's feature freeze [1] is at week 19 of the 28 week
    release cycle [2] (they normally are 26 weeks long but 10.10 was
    shortened for the 10-10-10 release date).

    Exceptions to the feature freeze can be approved by a board, but must
    have justification such as when reverting will cause more pain than just
    finishing it, or that the feature can be disabled by default without
    breaking other pieces so as not to block the release.

    I'd recommend that any cadence based release discussion at least examine
    Ubuntu's implementation and experiences given how successful it has
    been.

    The benefits to a large user base are huge. As consumers of Cassandra
    mature and the coupling with other software becomes tighter, it will be
    much more important that users can at least have some idea of release
    timing, even if they can't guarantee that the feature they want goes in.
  • Eric Evans at Jan 18, 2011 at 6:34 pm

    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 major versions less different. This would
    mean letting them live for shorter amounts of time and possibly
    making them bugfix only. Currently we add new features in stable
    branches, but I think if we made the major release schedule more
    predictable people would be more comfortable with letting their new
    feature wait until the next major version.
    I'll call your keep-close-to-trunk, and raise you a:

    * branch as soon as all planned features land in trunk
    * iteratively release betas w/ bug-fixes only
    * release candidates are actual candidates for the final (not
    releases)

    The time between creating the branch and making the release should be
    as short as practical, and there should be no backward incompatible
    changes between the first beta, and final release.
    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).


    --
    Eric Evans
    eevans@rackspace.com
  • Jonathan Ellis at Jan 19, 2011 at 4:30 pm

    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
    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
    that time frame.

    --
    Jonathan Ellis
    Project Chair, Apache Cassandra
    co-founder of Riptano, the source for professional Cassandra support
    http://riptano.com
  • Eric Evans at Jan 20, 2011 at 4:37 pm

    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 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?

    --
    Eric Evans
    eevans@rackspace.com
  • Ryan King at Jan 20, 2011 at 6:20 pm

    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 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.

    I'm guessing that we'll have to cut a bunch of scope in order to make
    this happen.

    -ryan
  • Eric Evans at Jan 20, 2011 at 7:50 pm

    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 go ahead and ship.
    I'm more worried about the inverse (the date slipping because of bugs),
    but sure.
    I'm guessing that we'll have to cut a bunch of scope in order to make
    this happen.
    Yes.

    --
    Eric Evans
    eevans@rackspace.com
  • Clint Byrum at Jan 20, 2011 at 9:01 pm

    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 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.
  • Stephen Connolly at Jan 20, 2011 at 9:14 pm
    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 ;-)

    - Stephen

    ---
    Sent from my Android phone, so random spelling mistakes, random nonsense
    words and other nonsense are a direct result of using swype to type on the
    screen
    On 20 Jan 2011 16:37, "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 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?

    --
    Eric Evans
    eevans@rackspace.com
  • Eric Evans at Jan 20, 2011 at 9:26 pm

    On Thu, 2011-01-20 at 21:14 +0000, 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
    eevans@rackspace.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescassandra
postedJan 13, '11 at 10:33p
activeJan 20, '11 at 9:26p
posts14
users5
websitecassandra.apache.org
irc#cassandra

People

Translate

site design / logo © 2021 Grokbase