> > 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.
