> > Yes, we should perhaps remove target version from the template, and > introduce guidance on describing stability impact etc.
Strong +1 to remove this from the template. I got sucked into the mistake of conflating implementation details and implications on where it lands instead of staying high level in the "do we agree we need this". And I'm a +1 on the "I agree we need this". On Wed, Jul 14, 2021 at 7:32 AM bened...@apache.org <bened...@apache.org> wrote: > > I think CEPs would benefit from describing their compatibility and > stability impacts, rather than trying to tie themselves to a > version, regardless of what context a specific version provides. > > Yes, we should perhaps remove target version from the template, and > introduce guidance on describing stability impact etc. > > Regarding waivers, I’m not sure we’ve really agreed as a community what > the criteria are for determining if work goes into a patch release – so I’m > not sure it would be right to call it a waiver. But I agree that scheduling > the release to contain some work should be a mixture of project roadmap > planning (distinct from CEP), and Jira/dev list discussion near the point > of merge. > > The question is if there is still value in the CEP pages maintaining the > endeavour’s goal for when the work will be ready, but perhaps this can be > communicated in normal date format, and used to inform project roadmap > planning. > > > From: Mick Semb Wever <m...@apache.org> > Date: Wednesday, 14 July 2021 at 10:41 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations > > > > PRs will land soon for people to look at, but honestly we’re getting into > > an unnecessary tangle over target release. I think it would be a mistake > to > > push this to a later release, because it is valuable and it will bring > pain > > by creating divergence - but the question a CEP is meant to answer is > _if_ > > the community wants a piece of work. > > > > Since it’s become an explicit point of contention, we can perhaps > > disaggregate a vote on _when_ to happen in parallel, once discussion on > > _if_ wraps up. > > > > Totally agree, can we remove the "Target Version" from the CEP, so the vote > is based on the _if_ ? > > Some further thoughts… > > I think CEPs would benefit from describing their compatibility and > stability impacts, rather than trying to tie themselves to a > version, regardless of what context a specific version provides. > > Rather than a subsequent vote on the CEP trying to get it into 4.0.x, what > about requests for waivers on each jira ticket as they are ready to land? I > suspect much of the work (once we see it) will be easier to agree to such > waivers than the only other position we have to stand by currently, which > is categories defined by SemVer. (A lot of people are really keen to see us > practice PATCH-only patch versions.) This also ties back to my request to > see a "rough timeline/plan of how the proposed changes are to be defined in > JIRAs and ordered." > > It's worth noting that the code divergence will happen between two branches > no matter what, e.g. 3.11, and next April is really not far away at all. Is > it really a problem if the LWT fix is also pushed back to 4.1 (though I > understand this is a bigger discussion) for the sake of driving home > we are a project now serious about stability? > > All in all, I am betting this discussion will be a lot more productive a) > when we see more of the work involved and its impact, and b) in a month or > two when we have better witnessed the stability of 4.0.0 and what has gone > into 4.0.1 and 4.0.2. >
