Re: Rough roadmap for 4.0
Hi, I think one additional issue to add to the pile is CASSANDRA-7544 "Allow storage port to be configurable per node" I think no matter what we land on implementation wise it will only possible to make this change in a major release as it will means change to the system schema as well as internode messaging protocol. Having this properly done and reviewed by January is optimistic. I think it wouldn't slip past February/March. Ariel On Tue, Nov 15, 2016, at 11:34 PM, Nate McCall wrote: > Agreed. As long as we have a goal I don't see why we have to adhere to > arbitrary date for 4.0. > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" > wrote: > > > I’ll comment on the broader issue, but right now I want to elaborate on > > 3.11/January/arbitrary cutoff date. > > > > Doesn’t matter what the original plan was. We should continue with 3.X > > until all the 4.0 blockers have been > > committed - and there are quite a few of them remaining yet. > > > > So given all the holidays, and the tickets remaining, I’ll personally be > > surprised if 4.0 comes out before > > February/March and 3.13/3.14. Nor do I think it’s an issue. > > > > — > > AY > > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (m...@thelastpickle.com) > > wrote: > > > > On 4 November 2016 at 13:47, Nate McCall wrote: > > > > > Specifically, this should be "new stuff that could/will break things" > > > given we are upping > > > the major version. > > > > > > > > > How does this co-ordinate with the tick-tock versioning¹ leading up to the > > 4.0 release? > > > > To just stop tick-tock and then say yeehaa let's jam in all the breaking > > changes we really want seems to be throwing away some of the learnt wisdom, > > and not doing a very sane transition from tick-tock to > > features/testing/stable². I really hope all this is done in a way that > > continues us down the path towards a stable-master. > > > > For example, are we fixing the release of 4.0 to November? or continuing > > tick-tocks until we complete the 4.0 roadmap? or starting the > > features/testing/stable branching approach with 3.11? > > > > > > Background: > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0" > > > > > And as 4.0 was initially supposed to come after 3.11, which is coming, > > it's probably time to have a home for those tickets. > > > > ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1" > > thread > > > > > three branch plan with “features”, “testing”, and “stable” starting with > > 4.0? > > > > > > Mick > >
Re: Rough roadmap for 4.0
Agreed. As long as we have a goal I don't see why we have to adhere to arbitrary date for 4.0. On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" wrote: > I’ll comment on the broader issue, but right now I want to elaborate on > 3.11/January/arbitrary cutoff date. > > Doesn’t matter what the original plan was. We should continue with 3.X > until all the 4.0 blockers have been > committed - and there are quite a few of them remaining yet. > > So given all the holidays, and the tickets remaining, I’ll personally be > surprised if 4.0 comes out before > February/March and 3.13/3.14. Nor do I think it’s an issue. > > — > AY > > On 16 November 2016 at 00:39:03, Mick Semb Wever (m...@thelastpickle.com) > wrote: > > On 4 November 2016 at 13:47, Nate McCall wrote: > > > Specifically, this should be "new stuff that could/will break things" > > given we are upping > > the major version. > > > > > How does this co-ordinate with the tick-tock versioning¹ leading up to the > 4.0 release? > > To just stop tick-tock and then say yeehaa let's jam in all the breaking > changes we really want seems to be throwing away some of the learnt wisdom, > and not doing a very sane transition from tick-tock to > features/testing/stable². I really hope all this is done in a way that > continues us down the path towards a stable-master. > > For example, are we fixing the release of 4.0 to November? or continuing > tick-tocks until we complete the 4.0 roadmap? or starting the > features/testing/stable branching approach with 3.11? > > > Background: > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0" > > > And as 4.0 was initially supposed to come after 3.11, which is coming, > it's probably time to have a home for those tickets. > > ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1" > thread > > > three branch plan with “features”, “testing”, and “stable” starting with > 4.0? > > > Mick >
Re: Rough roadmap for 4.0
On 16 November 2016 at 11:45, Aleksey Yeschenko wrote: > > Doesn’t matter what the original plan was. We should continue with 3.X > until all the 4.0 blockers have been > committed - and there are quite a few of them remaining yet. Thanks for the clarity, the quick reply I was hoping for :-)
Re: Rough roadmap for 4.0
I’ll comment on the broader issue, but right now I want to elaborate on 3.11/January/arbitrary cutoff date. Doesn’t matter what the original plan was. We should continue with 3.X until all the 4.0 blockers have been committed - and there are quite a few of them remaining yet. So given all the holidays, and the tickets remaining, I’ll personally be surprised if 4.0 comes out before February/March and 3.13/3.14. Nor do I think it’s an issue. — AY On 16 November 2016 at 00:39:03, Mick Semb Wever (m...@thelastpickle.com) wrote: On 4 November 2016 at 13:47, Nate McCall wrote: > Specifically, this should be "new stuff that could/will break things" > given we are upping > the major version. > How does this co-ordinate with the tick-tock versioning¹ leading up to the 4.0 release? To just stop tick-tock and then say yeehaa let's jam in all the breaking changes we really want seems to be throwing away some of the learnt wisdom, and not doing a very sane transition from tick-tock to features/testing/stable². I really hope all this is done in a way that continues us down the path towards a stable-master. For example, are we fixing the release of 4.0 to November? or continuing tick-tocks until we complete the 4.0 roadmap? or starting the features/testing/stable branching approach with 3.11? Background: ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0" > And as 4.0 was initially supposed to come after 3.11, which is coming, it's probably time to have a home for those tickets. ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1" thread > three branch plan with “features”, “testing”, and “stable” starting with 4.0? Mick
Re: Rough roadmap for 4.0
On 4 November 2016 at 13:47, Nate McCall wrote: > Specifically, this should be "new stuff that could/will break things" > given we are upping > the major version. > How does this co-ordinate with the tick-tock versioning¹ leading up to the 4.0 release? To just stop tick-tock and then say yeehaa let's jam in all the breaking changes we really want seems to be throwing away some of the learnt wisdom, and not doing a very sane transition from tick-tock to features/testing/stable². I really hope all this is done in a way that continues us down the path towards a stable-master. For example, are we fixing the release of 4.0 to November? or continuing tick-tocks until we complete the 4.0 roadmap? or starting the features/testing/stable branching approach with 3.11? Background: ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0" > And as 4.0 was initially supposed to come after 3.11, which is coming, it's probably time to have a home for those tickets. ²) The new versioning scheme slated for 4.0, per the "Proposal - 3.5.1" thread > three branch plan with “features”, “testing”, and “stable” starting with 4.0? Mick
[GitHub] cassandra pull request #84: removed local bind for outbound connections
Github user mmajercik closed the pull request at: https://github.com/apache/cassandra/pull/84 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
