Experimental Specification Features

[westonpace]

The requirement for votes can make it difficult to develop for a variety of reasons. Often, I want to get out a change before going through a vote process. For example, to test a fix in a real world environment (which often needs a wheel) or to get some experience with a feature in production before finalizing an implementation.

I would like to introduce formal rules for "experimental" features so that we can simplify the voting process. For a feature to be experimental the following prerequisites must be met:

1. It must be clearly marked as experimental (in both the protobuf and the docs)
2. It must be forward compatible (writers using the feature do not affect readers unaware of the feature)
3. It must be backward compatible (writers NOT using the feature do not affect readers using the feature)
4. Dropping the feature will not require a rewrite of data (e.g. some metadata flag will just go on being ignored). This is probably a superset of "forward compatible".

If all these criteria are met then I think the voting requirement should be waived if the following actions happen:

1. A vote discussion is started to stabilize the feature (this can be started even if the feature needs a few weeks of "run time" before stabilization, but it should be clearly marked)
2. Authors accept that if the vote is rejected, or expires, the feature will be removed.
3. Users accept that breaking changes may still be made to experimental features without any vote

[wjones127]

I like this idea. It might be worth testing this idea by thinking through how it will apply tot he file format. It sounds like:

1. You create a PR for the new encoding in the next file format
2. You create a vote for it.
3. You can merge the PR, knowing that the feature is experimental
4. BEFORE the next file format version is officially stabilized, you need the vote to close on the experimental encoding.

That sound right?

Authors accept that if the vote is rejected, or expires, the feature will be removed.

This is the key one to understand. They need to accept also that the PMC might request backwards incompatible changes to the feature. So it might be approved, but in a way that breaks someone who is already using the experimental feature.

[westonpace]

That sound right?

I was originally thinking in terms of indexes / table format, which don't have strict version gates. So I hadn't considered part 4. Still, I think that is fair. It helps encourage stabilization. Can I suggest one tweak:

4. BEFORE the next file format version is officially stabilized, you need the vote to close on the experimental encoding or push the encoding to the next version.

This is the key one to understand. They need to accept also that the PMC might request backwards incompatible changes to the feature. So it might be approved, but in a way that breaks someone who is already using the experimental feature.

I think this is fair, though to be avoided if possible.

[wjones127]

or push the encoding to the next version.

👍