Kicking off "RFC Edition"

[zkat]

I know we just did v2, and it was a lot, but some major, highly-valuable things have come up in the meantime, such as #495 and #494, that I think warrant a new version, particularly because v2 is still fresh and hasn't really had any time to propagate.

In the interest of including these changes, and establishing a more formal, long-term process for "finalizing" the language (hah), I think we should move to the RFC system. This would mean declaring the RFC document the "living spec" as long as RFC discussions are in progress, and moving away from semver and over to publish dates (during development) + RFC numbers (for future changes once an RFC is finalized).

I think the RFC process is a tried and true method for dealing with the challenges we've been having of wanting to make changes to the language in a non-disruptive, productive way.

As part of this, since v2 is still very young and basically unused, I wonder if we should just straight up deprecate the format and recommend against implementations supporting it. The changes we're looking at for the "RFC Edition" so far look like very small parser changes in practice, even if they're significant to users.

How do y'all feel about this? @kdl-org/implementers

[faekiva]

What's the benefit to deprecating it vs just letting it be the most current version?

[zkat]

Because if we're gonna do a new RFC edition, I really don't want v2 docs to start propagating through the ecosystem

[tjol]

I think we should avoid breaking backwards compatibility. KDL 2 is nice! Now, I'm all for making minor changes to the language based on everyone's experience with it, and versioning them appropriately. We'll find cases where the spec is unintuitive and can be improved with minimal disruption, like #495. Maybe somebody will come up with some useful syntax that we can introduce without breaking existing documents. In any case, surely the only real way to collect ideas for changes that we can be confident add value is for people to actually use v2.

As for how to version such non-disruptive changes: I don't have much of an opinion. SemVer is fine. The RFC approach is also fine. A hybrid approach ("KDL 2.1.0 a.k.a. RFC ?????") could also work, especially for a transition from one to the other.

Now, the slash thing (#494) — it seems to me that there's a perfectly good KDL-like language you could design that allows unquoted paths and URLs (which would be a nice feature) at the cost of significantly changing or even removing some other features, like the property syntax and – if # were used for comments – probably the raw string syntax and the keywords like #null. I wouldn't really expect a redesign on that scale to be a net positive, and that sort of thing certainly isn't the way to "finalize" anything.