Right. So I'm speculating everyone else who worked on a patch that breaks compatibility has been working under the mindset "I'll just put this behind the same switch". Or something more vague / even less correct, such as assuming that tries would become the default immediately.
At least in my mind when we talk about the "switch to enable tries" I do also consider things like "don't break streaming". So I guess whether one considers "a switch" to exist already or not, might be subjective in this case, because people have different assumptions on the definition of done of such a switch. henrik On Thu, Feb 23, 2023 at 2:53 PM Benedict <bened...@apache.org> wrote: > I don’t think there’s anything about a new format that requires a version > bump, but I could be missing something. > > We have to have a switch to enable tries already don’t we? I’m pretty sure > we haven’t talked about switching the default format? > > On 23 Feb 2023, at 12:12, Henrik Ingo <henrik.i...@datastax.com> wrote: > > > On Thu, Feb 23, 2023 at 11:57 AM Benedict <bened...@apache.org> wrote: > >> Can somebody explain to me why this is being fought tooth and nail, when >> the work involved is absolutely minimal? >> >> > I don't know how each individual has been thinking about this, but it > seems to me just looking at all the tasks that at least the introduction of > tries is a major format change anyway - since it's the whole point - and > therefore people working on other tasks may have assumed the format is > changing anyway and therefore something like a switch (is this what is > referred to as the C-8110 solution?) will take care of it for everyone. > > I'm not sure there's consensus that such a switch is a sufficient > resolution to this discussion, but if there were such a consensus, the next > question would be whether the patches that are otherwise ready now can > merge, or whether they will all be blocked waiting for the compatibility > solution first. And possibly better testing, etc. Letting them merge would > be justified by the desire to have more frequent and smaller increments of > work merged into trunk... well, I'm not going to repeat everything from > that discussion but the same pro's and con's apply. > > henrik > -- > > Henrik Ingo > > c. +358 40 569 7354 > > w. www.datastax.com > > > <https://urldefense.com/v3/__https://www.facebook.com/datastax__;!!PbtH5S7Ebw!dOQqeDGZHgRdaV7zT4J-u7QGa4b2HCSNBgF8KrDldGjvy_guOGUws3L2sV2X5y_vzNYF7iZ85aa0n0n_sPsT$> > <https://twitter.com/datastax> > <https://urldefense.com/v3/__https://www.linkedin.com/company/datastax/__;!!PbtH5S7Ebw!dOQqeDGZHgRdaV7zT4J-u7QGa4b2HCSNBgF8KrDldGjvy_guOGUws3L2sV2X5y_vzNYF7iZ85aa0n2bcAuFd$> > <https://github.com/datastax/> > > -- Henrik Ingo c. +358 40 569 7354 w. www.datastax.com <https://www.facebook.com/datastax> <https://twitter.com/datastax> <https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
