Documentation for xDS Delta API about quilkin HOT 4 OPEN

I think it depends on #884 because the changes in that issue would change the documentation, since we would change the types, and thus the documentation, and I'm reluctant to write docs that'd only be valid for one commit.

from quilkin.

I think it depends on #884 because the changes in that issue would change the documentation, since we would change the types, and thus the documentation, and I'm reluctant to write docs that'd only be valid for one commit.

I guess the only mitigating factor would be that if we want to cut a release, we would have an undocumented API surface at release time -- but we can make that decision when we are ready to make a new release 👍🏻

from quilkin.

I guess the only mitigating factor would be that if we want to cut a release

I think regardless of this specific feature, I think we want to move away from instant feature stability from version releases. As once we've started shipping "stable" versions, we're still going to want to merge features incrementally.

from quilkin.

I think regardless of this specific feature, I think we want to move away from instant feature stability from version releases. As once we've started shipping "stable" versions, we're still going to want to merge features incrementally.

100% Agreed (we use feature gates in Agones for exactly the same reason) - but even some kind of non-stable documentation with a warning of stability guarantee, would be useful if we do cut a release, so that end users can at least play with it and give feedback, etc.

For example, this is what we do on Agones:
https://agones.dev/site/docs/guides/player-tracking/

Not wedded to the format, but it's definitely useful for exactly the reasons you describe 👍🏻

from quilkin.