To close the loop on this thread: I don't think we need to do an
official vote here, but let's just put it on our calendars that we are
aiming to branch off 4.0 and freeze the first week of Sept.
-
To unsubscribe, e-mail: dev-unsu
Seems to me we should put September first to an official vote so we can
finish up with this mess.
On 13 April 2018 at 02:27, Rahul Singh wrote:
> I can commit some resources on my team - especially as we onboard some of
> our summer apprentices.
>
> I have some proprietary stress tools geared fo
I can commit some resources on my team - especially as we onboard some of our
summer apprentices.
I have some proprietary stress tools geared for Cassandra read / writes that
are a little better and creates a little more realistic data than Cassandra
stress.
--
Rahul Singh
rahul.si...@anant.us
I think the reason there's such a kerfuffle around a 'close-to-now'
freeze date is more of a concern as to when cassandra 5.0 is going to be
released. I'm assuming if people thought 5.0 was going to be released in
early 2019 no one would have a problem with setting the freeze date of
4.0 to _ri
September also works for Instaclustr.
On Fri., 13 Apr. 2018, 08:27 Jon Haddad, wrote:
> Sept works for me too. I’ll be involved in the validation process before
> the cutoff date.
>
>
> > On Apr 12, 2018, at 3:17 PM, Carlos Rolo wrote:
> >
> > I will commit time to test (not a full validation,
The thing is, good intentions are cheap. And they get cheaper the further
out in the future the point of action gets.
Realistically, the main difference between June and September is we ship
three months later. More, if we manage to land large, destabilizing patches
in the meantime. I’m very skep
Sept works for me too. I’ll be involved in the validation process before the
cutoff date.
> On Apr 12, 2018, at 3:17 PM, Carlos Rolo wrote:
>
> I will commit time to test (not a full validation, but at least go through
> operations) regardless of the date. Both seems fine to me.
>
> Regard
I will commit time to test (not a full validation, but at least go through
operations) regardless of the date. Both seems fine to me.
Regards,
Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
Pythian - Love your data
rolo@pythian | Twitter: @cjrolo | Skype
The Netflix team prefers September as well. We don't have time before that
to do a full certification (e2e and performance testing), but can probably
work it into end of Q3 / start of Q4.
I personally hope that the extra time gives us as a community a chance to
come up with a compelling user story
Hi,
+1 to September 1st. I know I will have much better availability then.
Ariel
On Thu, Apr 12, 2018, at 5:15 PM, Sankalp Kohli wrote:
> +1 with Sept 1st as I am seeing willingness for people to test it after it
>
> > On Apr 12, 2018, at 13:59, Ben Bromhead wrote:
> >
> > While I would prefer
+1 with Sept 1st as I am seeing willingness for people to test it after it
> On Apr 12, 2018, at 13:59, Ben Bromhead wrote:
>
> While I would prefer earlier, if Sept 1 gets better buy-in and we can have
> broader commitment to testing. I'm super happy with that. As Nate said,
> having a solid li
While I would prefer earlier, if Sept 1 gets better buy-in and we can have
broader commitment to testing. I'm super happy with that. As Nate said,
having a solid line to work towards is going to help massively.
On Thu, Apr 12, 2018 at 4:07 PM Nate McCall wrote:
> > If we push it to Sept 1 freeze
> If we push it to Sept 1 freeze, I'll personally spend a lot of time testing.
>
> What can I do to help convince the Jun1 folks that Sept1 is acceptable?
I can come around to that. At this point, I really just want us to
have a date we can start talking to/planning around.
--
If we push it to Sept 1 freeze, I'll personally spend a lot of time testing.
What can I do to help convince the Jun1 folks that Sept1 is acceptable?
On Thu, Apr 12, 2018 at 12:57 PM, Ben Bromhead wrote:
> I would also suggest if you can't commit to June 2 due to timing or feature
> set. If yo
I would also suggest if you can't commit to June 2 due to timing or feature
set. If you could provide the absolute minimum date / features that would
let you commit to testing, that would be useful.
On Thu, Apr 12, 2018 at 3:49 PM Ben Bromhead wrote:
> We (Instaclustr) are also happy to get star
We (Instaclustr) are also happy to get started testing. Including (internal
to Instaclustr) production workloads.
On Thu, Apr 12, 2018 at 3:45 PM Nate McCall wrote:
> To be clear, more who is willing to commit to testing should we go this
> route.
>
> On Fri, Apr 13, 2018, 7:41 AM Nate McCall w
To be clear, more who is willing to commit to testing should we go this
route.
On Fri, Apr 13, 2018, 7:41 AM Nate McCall wrote:
> Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
>
> We (tlp) will put some resources on this via going through some canned
> scenarios we have in
Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
We (tlp) will put some resources on this via going through some canned
scenarios we have internally. We aren't in a position to test data validity
(yet) but we can do a lot around cluster behavior.
Who else has specific stuff th
On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad wrote:
> It sounds to me (please correct me if I'm wrong) like Jeff is arguing that
> releasing 4.0 in 2 months isn't worth the effort of evaluating it, because
> it's a big task and there's not enough stuff in 4.0 to make it worthwhile.
>
>
More l
It sounds to me (please correct me if I'm wrong) like Jeff is arguing that
releasing 4.0 in 2 months isn't worth the effort of evaluating it, because
it's a big task and there's not enough stuff in 4.0 to make it worthwhile.
If that is the case, I'm not quite sure how increasing the surface area o
On 04/12/2018 10:57 AM, Michael Shuler wrote:
> Our current internal trunk test summary is attached. We're actually in a
> pretty good state on the baseline test suites, thanks to
> committers/reviewers.
>
> Due to compute resource limitations and error noise on py2->py3 update,
> the following te
Our current internal trunk test summary is attached. We're actually in a
pretty good state on the baseline test suites, thanks to
committers/reviewers.
Due to compute resource limitations and error noise on py2->py3 update,
the following test suites are not being run internally on our CI system,
s
On Thu, Apr 12, 2018 at 4:07 AM, Sylvain Lebresne wrote:
> I feel this discussion is starting to go in every directions and getting
> farther away from any decision/progress so I'll attempt to summarize what I
> hear, where I stand and *more importantly*, why.
>
> So as far as "what do we do for 4
On Thu, Apr 12, 2018 at 12:37 PM Stefan Podkowinski wrote:
> Maybe people would have preferred to know early about potential
> deadlines, before investing a lot of time into "pet ticket"
> contributions?
Of course, that's fair. And I apologize for the term "pet ticket", I
shouldn't
have used it
Maybe people would have preferred to know early about potential
deadlines, before investing a lot of time into "pet ticket"
contributions? It's hard enough to make assumptions about if and when
contributions make it into a release, but with feature freeze deadlines
falling from the sky any time, it
Here is what I think will happen if we don’t decide whether it will be 3 months
or more to gather support.
1. We freeze the features
2. No one works on testing it for months but I hope I am wrong
3. Features get merged in trunk.
4. We now need to cut 4.1 or whatever is next as this has more fea
On Thu, Apr 12, 2018 at 11:21 AM Sankalp Kohli
wrote:
> We can fix test after freezing if there are resources people are willing
> to put. We need to gather support to see who can help with the 3 points I
> have mentioned and when.
>
Again though, without disagreeing with your points, those don'
Also I am +1 freezing anytime even today if someone can show what the plan is
post freeze. May be I should start another thread to gather support for these
items
> On Apr 12, 2018, at 02:21, Sankalp Kohli wrote:
>
> We can fix test after freezing if there are resources people are willing to
We can fix test after freezing if there are resources people are willing to
put. We need to gather support to see who can help with the 3 points I have
mentioned and when.
On Apr 12, 2018, at 02:13, Sylvain Lebresne wrote:
>>
>> I agree there's little point freezing if we can't even test the
>
> I agree there's little point freezing if we can't even test the system
> properly.
>
I'll mention that I really don't follow the logic of such claim. Why can't
we
fix the testing of the system after freezing? In fact, isn't the whole
point of freezing agreeing that it's high time to fix that?
I feel this discussion is starting to go in every directions and getting
farther away from any decision/progress so I'll attempt to summarize what I
hear, where I stand and *more importantly*, why.
So as far as "what do we do for 4.0", I hear it boil down to 3 options:
1) we freeze June 1. It says
>
> I also don't see a place for minor releases as they exist today. It seems
> like they are almost all the overhead of a major release with unnecessary
> restrictions on what is possible.
Yeah this, I've never heard of anything that we don't do in "minors", and
it seems to me that everyone treat
If we have to decide on the date, we need to get confirmation on the
following which I mentioned earlier. We dont want to freeze things and no
one to make progress on
1. Who can sign up for fixing the tests(including upgrade tests). I don't
think we can release without tests passing. We can still
Hi,
What is the role of minor releases in Cassandra? I know that we have guarantees
we make about minor releases that we don't make about major releases (is this
summarized anywhere?), but is there anyone who actually thinks those guarantees
are worth it vs having major releases on a shorter sc
One clarifying point, potentially trivia, but:
On Wed, Apr 11, 2018 at 9:42 AM, Ben Bromhead wrote:
>
> We haven't seen any actual binding -1s yet on June 1, despite obvious
> concerns and plenty of +1s
>
>
Just to be clear: binding -1 votes are vetos for code changes, but they are
not vetos for
I'm on the side of freezing/branching earlier so we can really start the QA
process, but I do understand the concerns.
As Kurt alluded to previously, given our current release velocity, 4.1/5.0
will likely be some time away after 4.0. If we manage to release two high
quality stable major versions
I agree that not releasing semi-regularly is not good for the project. I think
our habit of releasing half working software is much worse though. Our
testing/stability story is not iron clad. I really think the bar for releasing
4.0 should be that the people in this thread are running the code i
On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa wrote:
> Seriously, what's the rush to branch? Do we all love merging so much we
> want to do a few more times just for the sake of merging? If nothing
> diverges, there's nothing gained from the branch, and if it did diverge, we
> add work for no real
Huh, I was writing my response for quite a while and getting distracted so
didn't see this, but yeah if I had a vote, this would obviously have it.
On 11 April 2018 at 03:03, Jeff Jirsa wrote:
>
>
> --
> Jeff Jirsa
>
>
> On Apr 10, 2018, at 5:24 PM, Josh McKenzie wrote:
>
> >>
> >> 50'ish days
>
> In thinking about this, what is stopping us from branching 4.0 a lot
> sooner? Like now-ish? This will let folks start hacking on trunk with
> new stuff, and things we've gotten close on can still go in 4.0
Agree with Jeff here that this is not necessary. The branch point should be
the feature
--
Jeff Jirsa
On Apr 10, 2018, at 5:24 PM, Josh McKenzie wrote:
>>
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
>
> What's a reasonable alternative / compromise for this? And what
> non-disru
Also in this time we should try to see who can do 3 things I mentioned in my
earlier email
> On Apr 10, 2018, at 17:50, Sankalp Kohli wrote:
>
> I think moving it to August/Sept will be better
>
> On Apr 10, 2018, at 17:24, Josh McKenzie wrote:
>
>>>
>>> 50'ish days is too short to draw a
I think moving it to August/Sept will be better
On Apr 10, 2018, at 17:24, Josh McKenzie wrote:
>>
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
>
> What's a reasonable alternative / compromise f
>
> 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
What's a reasonable alternative / compromise for this? And what
non-disruptive-but-still-large patches are in flight that we would want to
delay the line i
Seriously, what's the rush to branch? Do we all love merging so much we
want to do a few more times just for the sake of merging? If nothing
diverges, there's nothing gained from the branch, and if it did diverge, we
add work for no real gain.
Beyond that, I still don't like June 1. Validating rel
A lot of good points and everyone's input is really appreciated.
So it sounds like we are building consensus towards June 1 for 4.0
branch point/feature freeze and the goal is stability. (No one has
come with a hard NO anyway).
I want to reiterate Sylvain's point that we can do whatever we want i
Hi,
I am +1 on freezing features at some point.
Here are my thoughts
1. The reason it took 1.5 years b/w 3.0 and 4.0 is because 3.0 was
released(not cut) too early. There were so many critical bugs in it for
months after the release. Most people have just finished or about to
upgrade to 3.0. (
On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad wrote:
[ ... ]
> If they're not close to finished now why even consider them for
> the 4.0 release? They're so core they should be merged into trunk at the
> beginning of the cycle for the follow up release in order to get as much
> exposure as po
On Mon, Apr 9, 2018 at 10:56 PM Jonathan Haddad wrote:
> There's always more stuff to try to shoehorn in. We've done big releases
> with all the things, it never was stable. We tried the opposite end of the
> spectrum, release every month, that really wasn't great either. Personally
> I'd be O
> I'd like to see pluggable storage and transient replica tickets land, for
> starters.
So after all the fuss and scandal about incremental repair and MV not
stable and being downgraded to experimental, I would like to suggest that
those new features are also flagged as experimental for some time
If you are going to make 4 bigger as long as we call out that 3.11.x (or
whatever) will keep getting patches for stability only that's all that's
needed. We haven't gone to 3.x releases many places yet as we wait for a
release that will be stable longer. Knowing 4 is going to be bigger I
wouldn't w
>
> If they're not close to finished now why even consider them for the 4.0
> release?
Merging in major features at the end of a release cycle is not the path to
stability, imo.
On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad wrote:
> There's always more stuff to try to shoehorn in. We've done
There's always more stuff to try to shoehorn in. We've done big releases
with all the things, it never was stable. We tried the opposite end of the
spectrum, release every month, that really wasn't great either. Personally
I'd be OK with stopping new features by the end of this month and aiming
Myself I would put my non-binding vote for the stable side. I think those are
both important, but maybe they are best as some of the first things to go into
“release after 4.0”, not the last things to go into 4.0.
Maybe they would also prove as some incentive to get the next release out the
door
> I'd like to see pluggable storage and transient replica tickets land, for
> starters.
I think both those features are, frankly, necessary for our future. On
the other hand, they both have the following risks:
1. core behavioral changes
2. require changing a (relatively) large surface area of cod
I'd like to see pluggable storage and transient replica tickets land, for
starters.
On Mon, Apr 9, 2018 at 10:17 AM, Ben Bromhead wrote:
> >
> > For those wanting to delay, are we just dancing around inclusion of
> > some pet features? This is fine, I just think we need to communicate
> > what w
>
> For those wanting to delay, are we just dancing around inclusion of
> some pet features? This is fine, I just think we need to communicate
> what we are after if so.
>
+1 Some solid examples of tickets that won't make it with the proposed
timeline and a proposed alternative would help.
Otherw
seems
4.0 is a long way ahead for production usage.
Just my 2 EUR cents. 😊
Thanks,
Thomas
-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Freitag, 06. April 2018 06:01
To: dev
Subject: Re: Roadmap for 4.0
>>
>> So long as non-user-visible improvement
>
> Lay our cards on the table about what we want included in 4.0 and work to
> get those in
Are you saying we're back to where we started? 😉
For those wanting to delay, are we just dancing around inclusion of
> some pet features? This is fine, I just think we need to communicate
> what we a
>>
>> So long as non-user-visible improvements, including big ones, can still go
>> in 4.0 at that stage, I’m all for it.
>
>
> My understanding is that after June 1st the 4.0 branch would be created and
> would be bugfix only. It's not really a feature freeze if you allow
> improvements after that
>
> So long as non-user-visible improvements, including big ones, can still go
> in 4.0 at that stage, I’m all for it.
My understanding is that after June 1st the 4.0 branch would be created and
would be bugfix only. It's not really a feature freeze if you allow
improvements after that, which is
So long as non-user-visible improvements, including big ones, can still go in
4.0 at that stage, I’m all for it.
—
AY
On 5 April 2018 at 21:14:03, Nate McCall (zznat...@gmail.com) wrote:
>>> My understanding, from Nate's summary, was June 1 is the freeze date for
>>> features. I expect we wou
>>> My understanding, from Nate's summary, was June 1 is the freeze date for
>>> features. I expect we would go for at least 4 months (if not longer)
>>> testing, fixing bugs, early dogfooding, and so on. I also equated June 1
>>> with the data which we would create a 'cassandra-4.0' branch, and th
I'm in line w/your thinking here Jason.
On Thu, Apr 5, 2018 at 3:25 PM, Jonathan Haddad wrote:
> That’s exactly what I was thinking too.
>
> There’s also nothing preventing features from being merged into trunk after
> we create the 4.0 branch, which in my opinion is a better approach than
> tryi
That’s exactly what I was thinking too.
There’s also nothing preventing features from being merged into trunk after
we create the 4.0 branch, which in my opinion is a better approach than
trying to jam everything in right before the release.
On Thu, Apr 5, 2018 at 12:06 PM Jason Brown wrote:
> M
My understanding, from Nate's summary, was June 1 is the freeze date for
features. I expect we would go for at least 4 months (if not longer)
testing, fixing bugs, early dogfooding, and so on. I also equated June 1
with the data which we would create a 'cassandra-4.0' branch, and thus the
merge ord
June feels a bit too early to me as well.
I personally would go prefer end of August / beginning of September.
+1 to the idea of having a fixed date, though, just not this one.
—
AY
On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote:
June is too early.
On 05.04.18 19:3
June is too early.
On 05.04.18 19:32, Josh McKenzie wrote:
> Just as a matter of perspective, I'm personally mentally diffing from
> when 3.0 hit, not 3.10.
>
>> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
>> Author: T Jake Luciani
>> Date: Fri Nov 6 14:38:34 2015 -0500
>> 3.0 release
On 04/05/2018 12:32 PM, Josh McKenzie wrote:
> Just as a matter of perspective, I'm personally mentally diffing from
> when 3.0 hit, not 3.10.
>
>> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
>> Author: T Jake Luciani
>> Date: Fri Nov 6 14:38:34 2015 -0500
>> 3.0 release versions
>
>
Just as a matter of perspective, I'm personally mentally diffing from
when 3.0 hit, not 3.10.
> commit 96f407bce56b98cd824d18e32ee012dbb99a0286
> Author: T Jake Luciani
> Date: Fri Nov 6 14:38:34 2015 -0500
> 3.0 release versions
While June feels close to today relative to momentum for a
We can take a look on 1st June how things are then decide if we want to
freeze it and whats in and whats out.
On Thu, Apr 5, 2018 at 9:31 AM, Ariel Weisberg wrote:
> Hi,
>
> +1 to having a feature freeze date. June 1st is earlier than I would have
> picked.
>
> Ariel
>
> On Thu, Apr 5, 2018, at
Hi,
+1 to having a feature freeze date. June 1st is earlier than I would have
picked.
Ariel
On Thu, Apr 5, 2018, at 10:57 AM, Josh McKenzie wrote:
> +1 here for June 1.
>
> On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown wrote:
>
> > +1
> >
> > On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston
>
+1 here for June 1.
On Thu, Apr 5, 2018 at 9:50 AM, Jason Brown wrote:
> +1
>
> On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston
> wrote:
>
> > +1
> >
> > On 4/4/18, 5:48 PM, "Jeff Jirsa" wrote:
> >
> > Earlier than I’d have personally picked, but I’m +1 too
> >
> >
> >
> > --
> >
+1
On Wed, Apr 4, 2018 at 8:31 PM, Blake Eggleston
wrote:
> +1
>
> On 4/4/18, 5:48 PM, "Jeff Jirsa" wrote:
>
> Earlier than I’d have personally picked, but I’m +1 too
>
>
>
> --
> Jeff Jirsa
>
>
> > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote:
> >
> > Top-posting as
+1
On 4/4/18, 5:48 PM, "Jeff Jirsa" wrote:
Earlier than I’d have personally picked, but I’m +1 too
--
Jeff Jirsa
> On Apr 4, 2018, at 5:06 PM, Nate McCall wrote:
>
> Top-posting as I think this summary is on point - thanks, Scott! (And
> g
+1 and seriously hoping stuff marked "Patch available" will at least get a
chance of cutting in.
On Thu, 5 Apr 2018 at 12:43 kurt greaves wrote:
> >
> > Earlier than I’d have personally picked, but I’m +1 too
>
> This but +1.
>
> On 5 April 2018 at 03:04, J. D. Jordan wrote:
>
> > +1
> >
> > >
>
> Earlier than I’d have personally picked, but I’m +1 too
This but +1.
On 5 April 2018 at 03:04, J. D. Jordan wrote:
> +1
>
> > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote:
> >
> > Top-posting as I think this summary is on point - thanks, Scott! (And
> > great to have you back, btw).
> >
>
+1
> On Apr 4, 2018, at 5:06 PM, Nate McCall wrote:
>
> Top-posting as I think this summary is on point - thanks, Scott! (And
> great to have you back, btw).
>
> It feels to me like we are coalescing on two points:
> 1. June 1 as a freeze for alpha
> 2. "Stable" is the new "Exciting" (and the t
On Wed, Apr 4, 2018 at 7:50 PM, Michael Shuler
wrote:
> On 04/04/2018 07:06 PM, Nate McCall wrote:
> >
> > It feels to me like we are coalescing on two points:
> > 1. June 1 as a freeze for alpha
> > 2. "Stable" is the new "Exciting" (and the testing and dogfooding
> > implied by such before a GA
+1
On Wed, Apr 4, 2018 at 8:50 PM Michael Shuler
wrote:
> On 04/04/2018 07:06 PM, Nate McCall wrote:
> >
> > It feels to me like we are coalescing on two points:
> > 1. June 1 as a freeze for alpha
> > 2. "Stable" is the new "Exciting" (and the testing and dogfooding
> > implied by such before a
On 04/04/2018 07:06 PM, Nate McCall wrote:
>
> It feels to me like we are coalescing on two points:
> 1. June 1 as a freeze for alpha
> 2. "Stable" is the new "Exciting" (and the testing and dogfooding
> implied by such before a GA)
>
> How do folks feel about the above points?
+1
+1
:)
Michael
Earlier than I’d have personally picked, but I’m +1 too
--
Jeff Jirsa
> On Apr 4, 2018, at 5:06 PM, Nate McCall wrote:
>
> Top-posting as I think this summary is on point - thanks, Scott! (And
> great to have you back, btw).
>
> It feels to me like we are coalescing on two points:
> 1. Jun
+1, well said Scott.
> On Apr 4, 2018, at 5:13 PM, Jonathan Ellis wrote:
>
> On Wed, Apr 4, 2018, 7:06 PM Nate McCall wrote:
>
>> Top-posting as I think this summary is on point - thanks, Scott! (And
>> great to have you back, btw).
>>
>> It feels to me like we are coalescing on two points:
>
On Wed, Apr 4, 2018, 7:06 PM Nate McCall wrote:
> Top-posting as I think this summary is on point - thanks, Scott! (And
> great to have you back, btw).
>
> It feels to me like we are coalescing on two points:
> 1. June 1 as a freeze for alpha
> 2. "Stable" is the new "Exciting" (and the testing a
riginal Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID]
Sent: Wednesday, April 04, 2018 4:51 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0
The group seems to be trying to find a set of features that will define
version 4.0. I'm saying that makes things
Top-posting as I think this summary is on point - thanks, Scott! (And
great to have you back, btw).
It feels to me like we are coalescing on two points:
1. June 1 as a freeze for alpha
2. "Stable" is the new "Exciting" (and the testing and dogfooding
implied by such before a GA)
How do folks feel
major release. Let it
happen more naturally instead of forcing it.
Kenneth Brotman
-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID]
Sent: Wednesday, April 04, 2018 4:23 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0
I wouldn't want to ad
I wouldn't want to add anything to a release that isn't ready. Whatever
isn't ready can go in a future release.
-Original Message-
From: Scott Andreas [mailto:sc...@paradoxica.net]
Sent: Wednesday, April 04, 2018 4:18 PM
To: dev@cassandra.apache.org
Subject: Re: Road
will set the community up well for some awesome and exciting
> stuff that will still be in the pipeline if it doesn't make it to 4.0.
That sounds great to me, too.
– Scott
From: Kenneth Brotman
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@ca
: Roadmap for 4.0
On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
wrote:
> Can I suggest a way of defining the next few progressions as a way of
> approaching this?
>
> How about something like this:
> Version 4.0: A major release of as many improvements to the code as
>
On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
wrote:
> Can I suggest a way of defining the next few progressions as a way of
> approaching this?
>
> How about something like this:
> Version 4.0: A major release of as many improvements to the code as
> can be ready for a release on a d
[mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Wednesday, April 04, 2018 8:00 AM
To: dev@cassandra.apache.org
Subject: Re: Roadmap for 4.0
Agreed with Josh. There’s nothing set in stone after we release 4.0, trying to
extrapolate what we do here for the rest of humanity’s timeline
+1 to what Jon and Josh said.
At this point in time, an "exciting" 4.0 release to me is one that is
stable and usable with no perf regressions on day 1 and includes some of
the big internal changes mentioned previously.
This will set the community up well for some awesome and exciting stuff
that
Agreed with Josh. There’s nothing set in stone after we release 4.0, trying to
extrapolate what we do here for the rest of humanity’s timeline isn’t going to
be a useful exercise.
Regarding building a big list - it’s of no value. In fact, if we’re already
talking about releasing 4.0 we should
>
> This discussion was always about the release strategy. There is no
> separation between the release strategy for 4.0 and the release strategy
> for the project, they are the same thing and what is intended to be
> discussed here.
Not trying to be pedantic here, but the email thread is titled "
>
> I'm also a bit sad that we seem to be getting back to our old demons of
> trying
> to shove as much as we possibly can in the next major as if having a
> feature
> miss it means it will never happen.
That wasn't the intention of this thread, but that's the response I got.
Thought I made it pre
stages this year
before deploying into production. Production-wise, we are still "stuck" and
(more or less) happy with 2.1.
Thomas
-Original Message-
From: alek...@apple.com [mailto:alek...@apple.com]
Sent: Mittwoch, 04. April 2018 12:38
To: dev@cassandra.apache.org
Subject: R
3.0 will be the most popular release for probably at least another couple years
- I see no good reason to cap its support window. We aren’t Oracle.
—
AY
On 3 April 2018 at 22:29:29, Michael Shuler (mich...@pbandjelly.org) wrote:
Apache Cassandra 3.0 is supported until 6 months after 4.0 release
>
> A hard date for a feature freeze makes sense, a hard date for a release
> does not.
Strongly agree. We should also collectively define what "Done" looks like
post freeze so we don't end up in bike-shedding hell like we have in the
past.
On Tue, Apr 3, 2018 at 5:35 PM, Jeff Jirsa wrote:
>
A hard date for a feature freeze makes sense, a hard date for a release does
not.
--
Jeff Jirsa
> On Apr 3, 2018, at 2:29 PM, Michael Shuler wrote:
>
> On 04/03/2018 03:51 PM, Nate McCall wrote:
>>> My concrete proposal would be to declare a feature freeze for 4.0 in 2
>>> months,
>>> so say
1 - 100 of 110 matches
Mail list logo
