Hi all, Melissa of Constantia here (just back from PTO). Our plan is to share the community-approved blog with reporters who have expressed interest in Cassandra, which may result in coverage. We also developed a 4.0 beta graphic that anyone is welcome to use.
FWIW our timeline revolves around yours. We're ready to reach out just as soon as the beta is cut; no need to adjust anything on our behalf. If you're available for emailed or live interviews, please shoot me a note. We're here to help C*. I've spoken with a handful of folks already about how to best achieve that, and the door is open - reach out anytime! Melissa On Fri, Jul 17, 2020 at 11:23 AM Mick Semb Wever <m...@apache.org> wrote: > > If we agree to include this in beta-2, I'm OK with proceeding, but I > think we'll need a separate super-majority vote on ignoring the agreed beta > rules, which might be harder than just re-rolling the release? > > > This position, on a release vote, by precedence sounds more like a -0. A > valid concern has been raised, needs to be heard, but can and should be > resolved within this thread and vote. It has my vote to be added to 4.0- > beta2. > > > I think it's worth pointing out that this ticket was never marked with a > fix-version "4.0-alpha", so it was never visible as a blocker to the first > beta release. Being strict here IMHO would mean reverting the commit and > posting it to 4.1/5.0, rather blocking beta1. > > And… isn't the only thing that breaks API compatibility (and our beta > rules) > here is this one line: > > https://github.com/apache/cassandra/commit/d8993934e976d8edb94cbfe2974688dac63c5db5#diff-4805e34bd9553ede03778be66ddc06c7R268 > > > I can cut a new 4.0-beta1, no problems there. The bar to re-cutting a > proposed > release should be low enough that it's an easy enough call to request. I > will wait a few hours before doing so, to see what eventuates here… >
