I havent reviewed that code, but it's not surprising there would be
deprecated annotations in a major release. We *SHOULD* be deprecating
things that worked in 3.0/3.11 in 4.0, and removing them in a future
verison. We should only be removing them in 4.0 if they were originally
supported in 2.1/2.2
Hi,
I was going over StorageServiceMBean and I was quite surprised how
many deprecated methods there are. Only in that interface itself there
are 30 deprecation annotations. What is the general feeling about this
as 4.0 is getting more real? One would say that 4.0 is "breaking
change" release so I
> Proposing the test build of Cassandra 4.0-alpha4 for release.
The vote has passed after four days with 6 non-binding +1 vote, 9
binding +1 votes, and no -1 votes.
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
I think as long as we don’t publish the artifacts to maven central or some
other location that is for “anyone” we do not need a formal release. Even then
since the artifact is only meant for use by people developing C* that might be
fine.
If artifacts are only for use by individuals actively pa
Open an issue with the LEGAL jira project and ask there.
I'm like 62% sure they will say nope. The vote process and the time for
such is to allow for PMC to review the release to give the ASF a reasonable
degree of assurance for indemnification. However, we might have a fair
degree of leeway so lo
The most important thing for the purposes of what we’re trying to achieve
is to have a unique non overridable version. In principle, a unique tag
with release timestamp should be enough, as long as we can uniquely
reference it.
However, even then, I’d say release frequency (establishing “base”) fo
Thanks
On Wed, Apr 15, 2020 at 10:32 AM Mick Semb Wever wrote:
> > Can we vote(if required) on this as it looks largely everyone is in
> > agreement?
>
>
> I knew I forgot to post a reply here, thanks for the nudge sankalp, my bad.
>
> I took the above thread as consensus and last Friday committ
I don't think we need to vote on this. A few folks have expressed (very
justified) concern, but nobody has gone nuclear.
I intended on cleaning up the patch and getting it ready for another
review, but haven't had it in my brain and have been busy with other
things. I don't claim exclusive right
> Can we vote(if required) on this as it looks largely everyone is in
> agreement?
I knew I forgot to post a reply here, thanks for the nudge sankalp, my bad.
I took the above thread as consensus and last Friday committed it,
along with the documentation update from Eduard.
https://github.com/ap
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
I am not sure the PMC can simply vote away the ASF release rules here.
But it should be possible to implement the proposal by stepping away
from what the
+1
On Wed, Apr 15, 2020 at 12:22 PM Brandon Williams wrote:
> +1
>
> On Wed, Apr 15, 2020 at 8:35 AM Oleksandr Petrov
> wrote:
> >
> > Hi everyone,
> >
> > Apache release rules were made for first-class projects. I would like to
> > propose simplifying voting rules for in-jvm-dtest-api project
Can we vote(if required) on this as it looks largely everyone is in
agreement?
Also we can pile on documentation changes in the vote unless anyone
objects.
On Fri, Apr 10, 2020 at 2:52 PM Erick Ramirez
wrote:
> >
> > In a conversation with Mick we discussed keeping doc changes out as well.
> > A
What are the next steps? Do we hold a vote as I see few initial emails
which dont seem to agree and have not replied based on future discussions.
On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi wrote:
> +1 let's keep moving forward.
>
> Dinesh
>
> > On Apr 9, 2020, at 4:07 PM, Nate McCall wrote:
+1
On Wed, Apr 15, 2020 at 8:35 AM Oleksandr Petrov
wrote:
>
> Hi everyone,
>
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
>
> A bit of background: in-jvm-dtest-api is a project that is used by all
+1
On Wed, Apr 15, 2020 at 8:32 AM Yifan Cai wrote:
> +1
>
>
> From: Sam Tunnicliffe
> Sent: Wednesday, April 15, 2020 7:49:50 AM
> To: dev@cassandra.apache.org
> Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
>
> +1
>
> > On 15 Apr 2020, at 1
+1
From: Sam Tunnicliffe
Sent: Wednesday, April 15, 2020 7:49:50 AM
To: dev@cassandra.apache.org
Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov wrote:
>
> Hi everyone,
>
> Apache release rules w
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov wrote:
>
> Hi everyone,
>
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
>
> A bit of background: in-jvm-dtest-api is a project that is used by all
>
I like the idea, +1
> On 15 Apr 2020, at 10:30, Jon Haddad wrote:
>
> +1
>
>> On Wed, Apr 15, 2020, 6:58 AM Aleksey Yeshchenko
>> wrote:
>>
>> +1
>>
>>> On 15 Apr 2020, at 14:35, Oleksandr Petrov
>> wrote:
>>>
>>> Hi everyone,
>>>
>>> Apache release rules were made for first-class projec
+1
On Wed, Apr 15, 2020, 6:58 AM Aleksey Yeshchenko
wrote:
> +1
>
> > On 15 Apr 2020, at 14:35, Oleksandr Petrov
> wrote:
> >
> > Hi everyone,
> >
> > Apache release rules were made for first-class projects. I would like to
> > propose simplifying voting rules for in-jvm-dtest-api project [1].
+1
> On 15 Apr 2020, at 14:35, Oleksandr Petrov wrote:
>
> Hi everyone,
>
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
>
> A bit of background: in-jvm-dtest-api is a project that is used by all
>
+1
On Wed, Apr 15, 2020 at 10:21 AM Benjamin Lerer
wrote:
> +1
>
>
>
> On Tue, Apr 14, 2020 at 5:50 PM Blake Eggleston
> wrote:
>
> > +1
> >
> > > On Apr 14, 2020, at 5:09 AM, e.dimitr...@gmail.com wrote:
> > >
> > > I also can’t see them. I think it matters to which interface is the
> > link.
Hi everyone,
Apache release rules were made for first-class projects. I would like to
propose simplifying voting rules for in-jvm-dtest-api project [1].
A bit of background: in-jvm-dtest-api is a project that is used by all
active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
+1
On Tue, Apr 14, 2020 at 5:50 PM Blake Eggleston
wrote:
> +1
>
> > On Apr 14, 2020, at 5:09 AM, e.dimitr...@gmail.com wrote:
> >
> > I also can’t see them. I think it matters to which interface is the
> link.
> >
> > And +1 from me, thanks!
> >
> >> On 14 Apr 2020, at 7:53, Erick Ramirez
>
23 matches
Mail list logo
