Would such rule be strict or be just a guideline? What if there is a capability necessary only for certain language? In such cases there may be only a single language with given implementation. Examples. passing the context explicitly is currently necessary only for Go.

I don't think we want strict rules. This is to help us all (maintainers, spec sponsors) to gain confidence, not to impose restrictions. If it is for a single language then obviously we won't require 3 different language implementations :-)

I think creating such guidelines is good as these can help spec contributors to understand the "specification feature" lifecycles.

PS. I prefer calling such things guidelines rather than rules. Rules feel strict. Thus, my "fear" probably seen in my comment 😉 Also the referenced PR coins a rule (requirement).

My proposal:

• there SHOULD be at least 3 implementations to make something Stable
• the TC MUST verify that all implementations are indeed compliant with the specification that is being stabilized

My proposal:

The normative language is opposed to the idea that these are guidelines, rather than strict rules..

My proposal:

The normative language is opposed to the idea that these are guidelines, rather than strict rules..

SHOULD is not strict. These are the guidelines as requiring 3 implementations may be not realistic or even possible in some scenarios.

Regarding the strict MUST. If the TC are not verifying the compliance then I do not know how these implementations are really being important as they may have diverged. I see it like "testing the specification" before stabilization.

@tigrannajaryan, we are assuming you are the spec sponsor for this change.

@tigrannajaryan, we are assuming you are the spec sponsor for this change.

I'd like to put this in the TC inbox before we accept it, since I am not yet sure myself (that's why the question mark in the issue).

Recording my thoughts here: I think it's very important to require a certain number of implementations to exist before something can be marked as stable. This ensures the spec covers the solution end-to-end and has acceptable solutions that are not language-specific. In most cases, it would also mean that the feature has been exposed to end-users, allowing their feedback to be taken into account before we make a long-term commitment to support the feature.

There will be cases where we'd want to bypass this requirement, and I think it's OK to get a waiver for those cases.

I don't think making a hard requirement such as a "rule of three" is helpful. We use prototyping as a way to check our work and to verify our expectations. Which prototypes we need depends on what expectations we are trying to double check.

For API changes, we want to ensure that the new API can be implemented clearly across many languages that offer different language features – static vs dynamic, etc. Therefore, we want prototypes in different types of languages. Prototypes in three strongly typed languages would not help.

For plugin design, we want to ensure that the different types of known plugin behavior can be implemented effectively. Three implementations of the same sampler in three different languages would not help us determine if a sampler plugin design is correct. Instead, we would want to have prototypes of different types of samplers.

I recommend that we explain this logic as part of our spec development process– that the necessary prototypes should be determined up front, based on what aspects of the work will need to be verified and cross checked through implementation.

I agree that the rule of three would not be helpful for prototypes, which was the subject of #4273, but this is not asking for three prototypes. From what I understand, this issue and question is about implementations and when something is stable. In that case I agree that it would be important to require a certain number of implementations, agreeing with @jpkrohling's comment and reasoning.

However I also see an issue with a rigid number written in a normative way, one for the already given reason that something might only be relevant for one or two languages. But second, there might be cases where 3 languages have implemented something, but a fourth (or fifth,...) language catching up later will run into issues. So this would "punish" languages that either didn't pay attention on something being declared stable, or that have a long backlog not being able to catch up accordingly.

I argue that "declaring something stable" in the specification is worth a proper process. I know that it will add some additional disliked bureaucracy, but declaring something stable premature can be very harmful and is almost impossible to be reverted. So here is a proposal:

• There are 3 languages with an implementation, or less if there is a good reason for that (i.e. only relevant for that subset)
• TC verifies that those implementations are indeed compliant
• A pull request marking something as "stable" is labeled as such, i.e. we introduce a label "stable-marker" or whatever
• All language SIG maintainers get notified about this PR. They have 14 days(?) to veto and bring up their language-specific concern (or request an extension of the deadline if they think there might be an issue)
• After that waiting period (and sufficient approvals) the PR can be merged and the capability is declared stable

Note that labeling PRs that move a capability into another stability level would be valuable independently, right now it is really hard to identify those PRs, since all I can do is searching "mark stable" or similar across all PRs.

The TC is collectively going to sponsor / work on this.