At the end of the 7 day period, 26 issues remained with "4.0-triage" in
their fixversion. All 4.0-triage/alphe/beta/rc fixversions have been
removed from these remaining tickets and they are now flagged fixversion
4.0.x.
Thanks everyone.
On Thu, Oct 08, 2020 at 3:58 PM, Caleb Rackliffe
wrote:
Fair point on uncertainties and delaying decisions until strictly required
so we have more data.
I want to nuance my earlier proposal and what we document (sorry for the
multiple messages; my time is fragmented enough these days that I only have
thin slices to engage w/stuff like this).
I think
There is a sizeable cohort of us who I expect to be primarily focused on
3.0->4.0, so if you have a cohort focusing primarily on 3.11->4.0 I think we'll
be in good shape.
> For all subsequent major releases, we test and officially support only 1
> major back
I think we should wait to see what
I think it's a clean and simple heuristic for the project to say "you can
safely upgrade to adjacent major versions".
The difficulty we face with 3.0 is that it has made many contributors very
wary of pre 4.0 code and with good reason. Your point about conservative
users upgrading later in a
Since email is very unclear and context gets lost, I'm personally OK with
officially supporting all of these upgrade paths, but the spectre was raised
that this might lead to lost labour due to an increased support burden. My view
is that 3.0->4.0 is probably a safer upgrade path for users and
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encouraged. I
think we should encourage 2.1->3.0->4.0, while maintaining support for 2.2->3.0
and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal way
Some data that I believe is relevant here.
Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
the world (5,500 in China alone). In surveys (both informal polling and
primary research), at least 1/3rd of folks are running the 3.X latest if I
recall correctly.
Basic
> At The Last Pickle we have always recommended avoiding 3.0, including
> upgrading from 2.2 directly to 3.11.
> We (now DataStax) will continue to recommend that folk upgrade to the
> latest 3.11 before upgrading to 4.0.
>
To clarify that^, if it wasn't obvious, I wasn't making a statement about
ifesdjeen opened a new pull request #4:
URL: https://github.com/apache/cassandra-harry/pull/4
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL
>
> > Dropping support for upgrading from 3.0 to 3.11
>
> Nobody is proposing dropping support, but my personal preference would be
> to officially endorse encouraging users to go directly 3.0->4.0, which
> would reduce the support burden for 3.0->3.11 and 3.11->4.0, as many users
> will skip 3.11
> Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
> think that was required.
That's what's being discussed, and Mick is proposing requiring it officially,
to reduce support burden.
> What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Nothing that I'm aware
On 9 October 2020 at 10:23:02, Benedict Elliott Smith (bened...@apache.org)
wrote:
> I would personally prefer the community to officially recommend skipping 3.11
> to users
> that have not yet upgraded, as 3.0 and 4.0 have each had much more attention
> given to them
> over the past
I would personally prefer the community to officially recommend skipping
> 3.11 to users that have not yet upgraded, as 3.0 and 4.0 have each had much
> more attention given to them over the past several years.
What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Dropping support for
>
> Perhaps if others want to explicitly encourage the 3.0->3.11->4.0 upgrade
> path, we can split our resources accordingly?
>
Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
think that was required.
I would personally prefer the community to officially recommend skipping 3.11
to users that have not yet upgraded, as 3.0 and 4.0 have each had much more
attention given to them over the past several years. This would naturally lead
to fewer issues filed for 3.0->3.11 and 3.11->4.0, as fewer
Anyone have an opinion here or any formal prior art for us to build on?
>
Maybe this question should be more phrased as to which upgrade paths each
individual has time in helping and fixing users out?
If you are voting for official support for the 3.0 upgrade path then that
should imply you are
If a user asked me today, I would tell them to test the following paths
before attempting it in production:
- 2.1.x ---> 2.1.latest ---> 3.11.latest ---> 4.0
- 2.2.x ---> 2.2.latest ---> 3.11.latest ---> 4.0
- 3.0.x ---> 3.0.latest ---> 4.0
- 3.x --->
+1 to officially supporting 3.0 to 4.0, in addition to 3.11 to 4.0 upgrade
paths
On Thu, Oct 8, 2020 at 10:33 PM Jeff Jirsa wrote:
>
> I assumed it would be 3.0.x and 3.11.x
>
> I don’t know why we’d make 3.0-4.0 unofficial/unsupported - there’s no
> technical reason I’ve seen
>
> > On Oct 8,
18 matches
Mail list logo
