+1, but I want to know why only trunk and 4.0 ? not all the versions
involved, like 4.1 ,5.0 。
Francisco Guerrero 于2023年10月24日周二 07:47写道：
> +1 (nb). I think this is a great addition to offline tools that use
> SSTable writer in general.
>
> On 2023/10/23 23:21:13 Yifan Cai wrote:
> > Hi,
> >
>
+1 (nb). I think this is a great addition to offline tools that use SSTable
writer in general.
On 2023/10/23 23:21:13 Yifan Cai wrote:
> Hi,
>
> I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to
> trunk and hope we are all OK with it.
>
> In CASSANDRA-18941, I am adding
Hi,
I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to
trunk and hope we are all OK with it.
In CASSANDRA-18941, I am adding the capability to produce size-bounded
SSTables in CQLSSTableWriter for sorted data. It can greatly benefit
Cassandra Analytics
I have a strong preference to move out the 5.0 date to have accord and TCM. I
don’t see the point in shipping 5.0 without these features especially if 5.1 is
going to follow close behind it.
Dinesh
> On Oct 23, 2023, at 4:52 AM, Mick Semb Wever wrote:
>
>
>
> The TCM work (CEP-21) is in
I think this is a great more generally useful than the two scenarios you've
outlined. I think it could / should be possible to use an object store as the
primary storage for sstables and rely on local disk as a cache for reads.
I don't know the roadmap for TCM, but imo if it allowed for more
>From the folks I've been talking to - Accord is one of the biggest things to
>be excited about in 5.0. Everyone giving a presentation about the 5.0 release
>has been hyping up accord.
Shipping a release to make a date (that means practically nothing to most
people) by gutting one of the
On Mon, Oct 23, 2023 at 1:36 PM Jeff Jirsa wrote:
> Why ship a ghost release we dont really expect people to use. Why not just
> move the date so all the PR content highlighting TCM+Accord isnt a mess?
>
We won't move to 5.x until some time after the dust settles, and I can't
see us starting
>
> If I had to pick a month of the year to release software used by large
> enterprises, it probably would be something like March instead of December.
> I have no good research to back that up, of course...
>
Can confirm. Many large enterprises (especially retailers) have been in
"holiday code
Why ship a ghost release we dont really expect people to use. Why not just
move the date so all the PR content highlighting TCM+Accord isnt a mess?
I get it, nobody wants to move dates. Isn't that the least-bad option?
On Mon, Oct 23, 2023 at 11:28 AM Aleksey Yeshchenko
wrote:
> I’m not so
> If I had to pick a month of the year to release software used by large
> enterprises, it probably would be something like March instead of December.
That's... a good point. If we end up on a cadence of major's in December (since
we slipped to then for 4.1 and inherit that from that calendar
...or like the end of January. Either way, feel free to ignore the "aside"
:)
On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe
wrote:
> Kind of in the same place as Benedict/Aleksey.
>
> If we release a 5.1 in, let's say...March of next year, the number of 5.0
> users is going to be very
Kind of in the same place as Benedict/Aleksey.
If we release a 5.1 in, let's say...March of next year, the number of 5.0
users is going to be very minimal. Nobody is going to upgrade anything
important from now through the first half of January anyway, right? They're
going to be making sure their
To be clear, I’m not making an argument either way about the path forwards we should take, just concurring about a likely downside of this proposal. I don’t have a strong opinion about how we should proceed.On 23 Oct 2023, at 18:16, Benedict wrote:I agree. If we go this route we should
I agree. If we go this route we should essentially announce an immediate 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody rolling out 5.0 with 5.1 so close on its heels.On 23 Oct 2023, at 18:11, Aleksey Yeshchenko wrote:I’m not so sure that many folks will choose to go
I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path instead of
just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in one hop.
Nobody likes going through these upgrades. So I personally expect 5.0 to be a
largely ghost release if we go this route, adopted by few, just
We discussed that at length in various other mailing threads Jeff - kind of
settled on "we're committing to cutting a major (semver MAJOR or MINOR) every
12 months but want to remain flexible for exceptions when appropriate".
And then we discussed our timeline for 5.0 this year and settled on
On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever wrote:
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
I think this presumes that 5.0 GA is date driven instead
To double check the reasoning behind this proposal:
1) is 5.1 going to contain only TCM / Accord when it comes to new features? In
other words, 5.1, except these two, will only ever contain bugfixes from older
branches (merging them up) or fixes for TCM / Accord itself (which will be
> Sure, some like big shiny new numbers for new features and new APIs. But
if we follow the online upgrade-compatibility approach, clusters will be
able to upgrade from any 4.x to 5.1, therefore from the operators PoV the
"6" is not required.
> Aside from my desire to make our semver consistent
>
> Regarding the versioning scheme, if we follow the versioning scheme we
> have defined "by the book" then TCM/Accord would belong to a 6.0 version,
> which I have to admit feels a bit weird but it would signal to the user
> community that a major change is being introduced. I don't feel
> This has to be in 5.0, even if it’s alpha and ships after December, or this
> is going to be disaster that will take us much longer to unravel.
I'm curious to hear more about this.
> What is it going to take to get it into 5.0? What is off track and how did we
> get here?
I'm going to
>From a user perspective I have to say I was excited to see Accord/TCM being
released on 5.0 but at the same time a little nervous about seeing so many
overhauling features being shipped on the same release.
I think rushing last minute features hurts the stability goals we set for
the project. As
I’m going to be clearer in my statement.
This has to be in 5.0, even if it’s alpha and ships after December, or this
is going to be disaster that will take us much longer to unravel.
On Mon, Oct 23, 2023 at 7:49 AM Jeremiah Jordan
wrote:
> +1 from me assuming we have tickets and two committer
+1 from me assuming we have tickets and two committer +1’s on them for
everything being committed to trunk, and CI is working/passing before it
merges. The usual things, but I want to make sure we do not compromise on
any of them as we try to “move fast” here.
-Jeremiah Jordan
On Oct 23, 2023
I'm really surprised to see this email. The last I heard everything was on
track for getting into 5.0 and TBH and Accord is what a majority of users
are expecting in 5.0. And how could this be a .1 release?
What is it going to take to get it into 5.0? What is off track and how did
we get here?
+1 from me too.
Regarding Benedict's point, backwards incompatibility should be minimal; we
modified snitch behaviour slightly, so that local snitch config only relates to
the local node, all peer info is fetched from cluster metadata. There is also a
minor change to the way failed bootstraps
I’m cool with this.
We may have to think about numbering as I think TCM will break some backwards
compatibility and we might technically expect the follow-up release to be 6.0
Maybe it’s not so bad to have such rapid releases either way.
> On 23 Oct 2023, at 12:52, Mick Semb Wever wrote:
>
>
The TCM work (CEP-21) is in its review stage but being well past our
cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
like to propose the following.
We merge TCM and Accord only to trunk. Then branch cassandra-5.1 and cut
an immediate 5.1-alpha1 release.
I see this as a
According to the conclusion, I think we can fix the bug when the argument
number is bigger than 2 first.
Thanks everyone.
Bowen Song via dev 于2023年3月23日周四 22:17写道：
> In that case, I would recommend fix the bug that prints everything when an
> arbitrary number of arguments is given.
> On
29 matches
Mail list logo
