Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

2019-06-25 Thread Oleksandr Petrov
Maybe a bit off-topic:

Before we cut a release, we should make sure we take care of beta protocol
[1], include released driver versions [2] and remove compact storage
remainders [3]. Third one is optional, but I'd argue we should do it sooner
rather than later.

[1] https://issues.apache.org/jira/browse/CASSANDRA-14973
[2] https://issues.apache.org/jira/browse/CASSANDRA-13951
[3] https://issues.apache.org/jira/browse/CASSANDRA-13994



On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> Thanks for the feedback Scott. I have incorporated all the incremental
> feedback I have thus far.
>
> Looking for any additional feedback folks may have.
>
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
>
> On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas 
> wrote:
>
> > Thanks for starting this discussion, Sumanth! Added a round of comments
> as
> > well.
> >
> > Summarizing my non-binding feedback: I feel that many of the items under
> > "Alpha" and "Beta" should be achieved prior to the release of an alpha,
> > especially those related to correctness/safety, scope lock, feature
> > completeness, deprecation, and backwards compatibility. Establishing a
> > higher standard for official project releases (even at the alpha and beta
> > stage) will help us really polish the final build together.
> >
> > Ideally, I feel that contributors should have completed extensive
> > testing/validation to ensure that no critical or severe bugs exist prior
> to
> > the release of an alpha (e.g., data loss, consistency violations,
> incorrect
> > responses to queries, etc). Perhaps we can add a line to this effect.
> >
> > Ensuring that we've met that bar prior to alpha will help us focus the
> > final stages of the release on gathering feedback from users + developers
> > to validate tooling and automation; compatibility with less commonly-used
> > client libraries, testing new features, evaluating performance and
> > stability under their workloads, etc.
> >
> > – Scott
> >
> > On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> > Thanks for the feedback on the product stages/ release life cycle
> > document.
> > I have incorporated the suggestions and looking for any additional
> > feedback
> > folks may have.
> >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
> >
> > Thanks,
> > Sumanth
> >
> > On Tue, May 28, 2019 at 10:43 PM Scott Andreas  >
> > wrote:
> >
> > > Echoing Jon’s point here –
> > >
> > > JH: “My thinking is I'd like to be able to recommend 4.0.0 as a
> > production
> > > ready
> > > database for business critical cases”
> > >
> > > I feel that this is a standard that is both appropriate and
> > achievable,
> > > and one I’m legitimately excited about.
> > >
> > > Re: the current state of the test plan wiki in Confluence, I owe
> > another
> > > pass through. There has been a lot of progress here, but I’ve let
> > perfect
> > > be the enemy of the good in getting updates out. I’ll complete that
> > pass
> > > later this week.
> > >
> > > Cheers,
> > >
> > > — Scott
> > >
> > > > On May 28, 2019, at 10:48 AM, Dinesh Joshi 
> > wrote:
> > > >
> > > > +1. Wiki could be useful to document what the overall plan. Jira
> to
> > > track progress.
> > > >
> > > > Dinesh
> > > >
> > > >>> On May 28, 2019, at 10:20 AM, Joshua McKenzie <
> > jmcken...@apache.org>
> > > wrote:
> > > >>>
> > > >>>
> > > >>> The unofficial rule is to not upgrade to prod till .10 is cut.
> > > >>
> > > >> FWIW, I believe it's historically .6. Which is still not a great
> > look
> > > for
> > > >> the project.
> > > >>
> > > >> There's a ton of work going into testing 4.0 already.
> > > >>
> > > >> While I intuitively and anecdotally (from the people I've
> > backchanneled
> > > >> with) believe this to be true as well, the referenced wiki
> > page[1] and
> > > >> jql[2] doesn't look like it's an up to date reflection of the
> > testing
> > > >> efforts going on. Is there another place this information is
> > stored /
> > > >> queryable we can surface to people to keep us all coordinated?
> > > >>
> > > >> [1]
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> > > >> [2]
> > > >>
> > >
> >
> https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA
> > > >>
> > > >> On Tue, May 28, 2019 at 12:57 PM sankalp kohli <
> > kohlisank...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Hi Jon,
> > > >>>  When you say 4.0 release, how do u match it with 3.0
> > minor
> > > >>> releases. The unofficial rule is to not upgra

Cassandra v4.0 Documentation Update [Google Season of Docs]

2019-06-25 Thread Immanuel


Hello,

I am new to the community and interested in helping with documentation update 
for Cassandra 4.0 release. 

I am writing to ask about the parts of the current documentation that needs to 
be updated to reflect the changes and improvement made in Cassandra v4.0 before 
release.

I hope to get your various inputs.

Thank you.

Immanuel.


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org