Document minimal process necessary for the interim release

[jdesrosiers]

Progress on defining a specification development and release process is blocked, but work is moving forward on producing the next release. However, since we've decoupled from IETF, we no longer have a definition of what it means to release a spec. This document is an attempt to define the bare minimum of what is necessary to release something. I tried to avoid anything I thought might be remotely controversial. If there's anything you aren't comfortable with let me know and I'll take it out, or make it more vague, or whatever is necessary. I'm not trying to push anything controversial.

I've used the word "experimental" to describe what we've been calling "unstable". At least one person has interpreted the word "unstable" in a way other than I intended, so I'm trying something else. Happy to take other suggestions.

I've used the word "behaviors", rather than what we've been calling "features" (including keywords). I'm hoping that makes it more clear that observable behaviors are what are subject to compatibility requirements. For example, when the spec prescribes a mechanism for something such as annotations for inter-keyword communications, that can be changed as long as the observable behavior is equivalent.

I included a super simple binary (stable or experimental) stability model. We heard at the last OCWM that not everyone is necessarily on board with including unstable behaviors in the spec. I figured defining it as a tool we can use doesn't hurt. If we decide we don't want to use that tool, we don't have to. Or, I can take it out.

Similarly, I included a definition for deprecation although there has been some discussion in that area and I'm not sure everyone agrees it's a tool we should use. I would have left it out as something we don't need to define for an initial release, but I included it because there was a suggestion in the OCWM of including behaviors in the next release as initially deprecated. We don't have to use it if we choose not to, but it's there. Or, I can take it out.

[gregsdennis]

I'm happy with this. Time to go get signatures from others.

[Julian]

Just to nitpick, this doesn't necessarily have to be the case "in practice". E.g. if an implementation whitelists dialect identifiers (as most do today), and if each release has a dialect identifier going forward (as is the status quo), but an implementer doesn't remember to add a bunch of old dialect URIs to their implementation (seems likely) to "turn them on", then in practice, the implementation won't actually proceed validating release 2023 if the implementation was written for 2024 and its author forgot to add the 2023 URI to their mapping of "known dialects".

In practice I think this actually will indeed happen at various points, so maybe it's mildly nice to weaken this sentence to just say "implies likely support" or something but if you want to leave as-is it's not a big deal either.

[jdesrosiers]

I don't think we need to account for implementation bugs in the wording here. Bugs happens, but I don't think we need to allow for it, I think we need to consider implementations with those kinds of bugs out of compliance until they fix the bug. Maybe the wording needs to be tweaked to express that better.

However, I noticed a related problem. The deprecation section says that implementers "SHOULD" (not "MUST") support deprecated behaviors. If we allow implementations to not support deprecated behaviors, then they aren't in compliance for releases before that behavior was deprecated. The wording here will need to take that into account.

[Julian]

Left minor comments but looks good here too.

[awwright]

I support having and following a process, but this mostly seems to list implementation constraints that will be part of the specifications anyways.

When defining any process or stability guarantees, I would expect language that assigns responsibilities in the form of "Party will..." or "Party shall..." e.g.

JSON Schema org will publish specifications for describing and validating JSON documents, each at a cool URI; first a JSON-based media type, then subsequent revisions and/or new related publications, as long as each maintains compatibility with the requirements and (compliant) implementations of previous specifications.

In particular, RFC 2119/BCP 14 is probably not applicable here since those are supposed to be constraints on implementations for interoperability purposes. Even though I've seen people try to shoe-horn BCP 14 language into meta-specifications (charters, etc), using them like this doesn't make much sense:

In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.

(RFC 2119 using its own keyword is a weird borderline case where it's not imposing interoperability requirements per se, but when a technical specification incorporates the language by normative reference, then it makes sense.)

• Canonical URLs — I'm not sure this needs much elaboration, if necessary, just link to Cool URIs.
• Compatible Releases — This both is eminently obvious and not specific enough... is this a section I could point to and it would be obvious why specifications up to this point have not been stable enough?
• Experimental Behaviors — Experimental behaviors should be in separate documents and not mingled with stable documents. If you can't split stable parts from the rest, then those parts aren't actually stable.
• Compliance — We don't actually have authority to order around implementations, we only set the conditions on what being a compliant implementations means—and this is otherwise just a tautology "to be compliant with the specification you must be compliant with the specification"
• Deprecation — Technically speaking, deprecation refers to any behavior that must not be produced, but must be supported. If we want to deprecate something, then we'll just define the requirements like that.

In general I'm fine with a charter-like document that defines what the output shall be, but this would better be an issue, milestone, or blog post; defining rules that implementations must follow steps on the editor's toes a bit.

[jdesrosiers]

this mostly seems to list implementation constraints that will be part of the specifications anyways.

I disagree. I specifically crafted this document to only include things that I don't think belong in the specification. It describes how one release relates to another release, it defines a set of constraints that we as spec authors must follow when producing new versions of the spec, and it describes processes that might apply to multiple spec documents (i.e. Core and Validation). A specific release should describe how to implement the version of JSON Schema that that release specifies. How that release relates to other releases is a separate concern and covered by this document. If you can provide specific things that you think belong in a spec document rather than here, let me know and we can discuss it.

When defining any process or stability guarantees, I would expect language that assigns responsibilities in the form of "Party will..." or "Party shall..." e.g.

I'll try to work that in.

RFC 2119/BCP 14 is probably not applicable here since those are supposed to be constraints on implementations for interoperability purposes.

Yes, I did feel like it was a bit of a stretch, but in the end, RFC 2119/BCP 14 is about disambiguating natural language and that's why I chose to use it. In this context the "implementation" is the spec document that we are producing. Given that context, I think the usage fits and makes sense in most places, but there are definitely a few places where it's being used in the context of implementations and that should be removed. Formal constraints in this document should only apply to the specification not implementations.

Canonical URLs — I'm not sure this needs much elaboration, if necessary, just link to Cool URIs.

I was definitely thinking about Cool URIs when I wrote this, but I think of "Cool URIs" as a term that never caught on. I don't think including it adds anything and I figured no one would know what I was talking about anyway. But, if you think it's important, I'll include it.

Compatible Releases — This both is eminently obvious and not specific enough

It's certainly not obvious. If it was, we wouldn't have been discussing it (and often disagreeing) for the last year. This is very much something that needs to be made clear in writing.

However, I do agree that it isn't specific enough, but that's mostly on purpose. The main reason is that the specifics should be in the specification, not here. For example, how we achieve forward compatibility is out of scope for this document. This document defines forward compatibility as a requirement, but the spec must determine the mechanisms by which forward compatibility is achieved.

Another other reason I left some things vague on purpose is because we haven't agreed on the details yet. I left "Note" sections calling out some of the major gaps, but there are other gaps as well. For now, we are unconstrained where there are gaps, but I expect the gaps to be filled in later as we agree on more of the details.

Finally, this is just supposed to be a starting point we can iterate on. It isn't final and doesn't have to decide every detail now or ever. As we determine things need to be defined in more detail, we can update the document.

I'm sure there are also places where I was unintentionally too vague as well. If there are specific things you can call out that are too vague, I'm happy to address them.

is this a section I could point to and it would be obvious why specifications up to this point have not been stable enough?

No. This section isn't intended to answer that question. This is not intended to be a historical account or include explanation for how or why we got here. The intention is to define what we are doing going forward. We should probably have a blog post that we can point to that answers that questions, but I think that's out of scope here.

Experimental Behaviors — Experimental behaviors should be in separate documents and not mingled with stable documents.

That's debatable, but I don't want to get into that debate it here. I said in the PR description,

We heard at the last OCWM that not everyone is necessarily on board with including unstable behaviors in the spec. I figured defining it as a tool we can use doesn't hurt. If we decide we don't want to use that tool, we don't have to. Or, I can take it out.

A decision isn't going to be made in this PR. It will require more discussion and an additional PR. So, what are you comfortable with including here? Can we include it as tool without committing to using it? Would it be more acceptable if there was an explicit note saying we might not use it? Would you rather we completely leave it out for now until we discuss it further? I'm fine with any of those, just let me know.

Compliance — We don't actually have authority to order around implementations, we only set the conditions on what being a compliant implementations means

The intention here is only to define what it means to be a compliant implementation. What part makes it sound like we are trying to order around implementations? I'm happy to change it. Are you referring to statements that say "implementations MUST" and "implementations SHOULD"? I think it's reasonable to argue that this document shouldn't put formal constraints on implementations, it should only put formal constraints on specification authors. I'll see if I can reword or at least soften "MUST" and "SHOULD" to "must" and "should".

this is otherwise just a tautology "to be compliant with the specification you must be compliant with the specification"

That's not what the document says. The statement that it should implement all behaviors sounds obvious, but it's proven necessary that we have to say it. Some implementations (even very popular implementations like ajv) claim support for 2019-09 or 2020-12, but don't support some features or add behaviors that aren't entirely compatible with the spec.

Arguably, we don't need to define "compliance" here. If people think it's out of scope here, I can remove it, but I think it's important that it's formally defined somewhere.

Deprecation — Technically speaking, deprecation refers to any behavior that must not be produced, but must be supported.

"Deprecated" is one of those software terms that doesn't have one clear definition. At least colloquially, people understand a variety of different things when they read that word. We need to define what we mean if we decide to use it.

If we want to deprecate something, then we'll just define the requirements like that.

I disagree, but that's not really the point of this section. The point is to define and document a consistent approach to deprecation (and/or removal) that we will stick to when evolving the spec. If we decide that the approach is to define the requirements according to the definition you gave, then that's what should be documented here.

This section doesn't say much now, but I expect it to evolve to include more constraints on what we are allowed to do in the spec. For example, if we decide that a deprecated behavior can never be removed from the spec, that constraint would be defined here.

this would better be an issue, milestone, or blog post; defining rules that implementations must follow steps on the editor's toes a bit.

This document is not about defining rules that implementations must follow, it's about defining rules that we, the spec authors, must follow. I'll revise with that in mind and remove anything that might veer too far away from that. I very strongly believe we need a document where we define how we approach spec development. Trying to write such a document has only underscored that we are not all on the same page. Coming up with a formal document is the only way to ensure that we all have the same expectations. Even if we don't all agree what we should do, it should be unambiguous what we're actually doing.

[karenetheridge]

I like the intent of this document but a lot of things need more clarification, and I think the stable/unstable default should be reversed.

[karenetheridge]

What does "stable" mean here? That the URL should never change for a given specification version? or is it also saying that the contents of that URL (the schema itself) must not change? I would tend towards the former, and explicitly state that the contents MAY change from time to time, but only to reflect corrections to mistakes (or to add further refinement to things already in the spec), never to revise the actual intent of validation.

That is:

• we found an error in the schema that doesn't match the spec. it is acceptable to revise the schema to properly reflect what the spec says.
• something wasn't in the schema because we didn't see a way of expressing a particular thing in the spec, but then later we see a way of doing so. it is acceptable to revise the schema to add the new check.
• we issue a minor revision to the spec (e.g. to clarify a point that was vague before). it is acceptable to add something to the schema to express this clarification.
• we change our mind about how a keyword works, which contradicts the current spec. it is NOT acceptable to make this change in the current schema - it needs to be deferred to the next major release.

[jdesrosiers]

This is only referring to the URL, not the content of what the URL identifies. I'll make an update to try to make that more clear.

All of those points are important for us to decide on and document, but I was expecting to discuss and document those details separately. My goal here is to get down the parts that we can all agree on without major discussion and build from there in separate discussions/PRs. So, at this point, I expect most of this document to be underspecified. In those cases, we are unconstrained for now.

[karenetheridge]

When will the URL change? We just finished saying that it's stable.

[jdesrosiers]

There's no normal reason it should ever need to change. Maybe we choose a URI template to use now and then later we decide that for some reason it would be easier to maintain if we used a different template. This is saying we can do that, but we have to it in a way that won't cause 404s somewhere out on the web.

I think it's extremely unlikely that we would ever want to change a canonical URL, but it's there in case some unusual circumstance forces us or we think we have a really good reason.

[karenetheridge]

I don't think it's a good idea to default to everything being stable -- it will require that we have to be extra-rigorous about finding and marking all the "not yet stable" items for the next release, and if we overlook something, we're screwed. It would be better to default to unstable, and explicitly mark those things we think are now stable.

[jdesrosiers]

I think default-stable is definitely the place we want to be, but it doesn't have to be the place we start if we think we aren't confident enough to do that yet. It might be best not to say what the default is for now and discuss that separately.

[karenetheridge]

I'm not really sure how you're defining forward- and backward-compatible here. Some examples might help.

[karenetheridge]

We could instead just say "new specification versions shall be released from time to time on a schedule still to be determined", which leaves us much more flexibility later as to what process to adopt.

[jdesrosiers]

I'm not seeing how that's different than what the text already says.

[karenetheridge]

This sentence implies that stable items are explicitly defined (which is what I think we should do, but not what this document states).

[jdesrosiers]

I don't think that sentence implies anything about how stable items are defined, but I'll see if I can make it less ambiguous.

Is it the word "required" that makes you interpret it that way? I included that to make it clear that an optional feature (like the annotation-assertion vocabulary) doesn't need to be implemented even though it's a stable feature.

[karenetheridge]

But this isn't true right now. It may be true in the future, when we figure out what "backwards compatible" means, but that's premature for this set of changes.

[jdesrosiers]

I'll try to make it more clear. This document applies only to releases that were produced using this process.

[karenetheridge]

Unstable things could also be deprecated - e.g. "we put this in as an experiment, and it didn't work out, so we're going to remove it in the next release".

[jdesrosiers]

I hadn't thought about using deprecation that way. Deprecation is one of the things we know needs more discussion. I'll try to reword the current text in a way that doesn't restrict us from deciding to use it that way.

[Relequestual]

I'm in the process of leaving a review of this PR, and wanted to share something directly, specifically @Julian's somewhat hidden (not intentially) comment in the Google Sheet linked to in json-schema-org/community#282 regarding keyword stability suggestions. (I can't actually easily see it all on the Sheet page even.)
 

I'm (Julian) adding a sheet and this note to represent an opinion I mentioned on the December 5 OCWM and expanded on on the 12, which I think I'm increasingly convinced of personally, though I recognize others seem to still be significantly further along the spectrum of instability. Namely, you'll note that the "Stability" column here for myself essentially labels everything "Stable", other than keywords which have been deprecated (which I suspect we can/should remove entirely at this point).

This notion of stability comes from a claim or assumption that we deem things stable already by virtue of putting them in released specifications, and that essentially a large portion of lag comes from users trying to figure out changes to their schemas from one version to the next. In short therefore, my opinion is that we should not change any existing released keyword in backwards incompatible ways, and should either deprecate and remove keywords when we wish to change them going forward as of today, or we should refrain from the change entirely. I believe many (if not most) users already expect this kind of stability model, and that therefore explicitly marking things as unstable is essentially downgrading a stability guarantee some folks will have relied on -- whether they're correct in doing so not being relevant, as of course implementers (or here spec authors) would always love it if users didn't rely on things they weren't meant to rely on, but alas, users use stuff when you put it out!

Concretely as an example, I'd personally support backing out the contains change -- not because it expands contains to a new type, which is backwards compatible, but because its behavior now changes unevaluatedProperties. The above in mind, I can't say I've fully looked through all of the other keywords and confirmed I really do have no other instances where I'm aware of an existing backwards incompatible change -- Henry's changelog would seem to indicate that the only possible other relevant one is (banning) $id with a fragment, which I don't know whether anyone does actively (if people do, I'd indeed personally put it in the same bucket, and if not, then I'd be indifferent to changing it).

To mention another bit that came up on the call - I'd definitely not have any issues with additional new keywords (e.g. propertyDependencies) being added, but I would personally expect them to be immediately stable when added (unchangeable without deprecation).

The same applies to other areas we seem to have general agreement need large changes, e.g. $vocabulary -- I'd support the change, but would expect it to be done in some backwards compatible way (whether that means changing the name of the new keyword, or otherwise having behavior which doesn't interact with "old usages").

Why share this? I think it shows a different opinion and view than most others here, however I also feel it has a lot of good points.
Should we conceed some or most of these points, it could be "easily" rectified (moving forward) by simply not including any non-stable things in the "live" specification document, or avoiding the "living" spec alltogether, keeping it as development only with some defined release cycle. Of course, we could put out "release preview vocabularies" for those who want to play on the edge.

So what?
I think this shows we're still not super sure if what we're doing here is quite right, or if we need to re-think our approach.
I feel like I need ot review the last two calls to recap what was said. (json-schema-org/community#278, json-schema-org/community#285)

[gregsdennis]

I just had an idea, and I can't find the discussion so I'm putting it here. I think this only pertains to keywords, but we may be able to apply it to non-keyword features as well somehow.

Instead of labeling, marking, or otherwise identifying features as stable, we have a naming convention that indicates that. For example, while we're working on propertyDependencies, we call it exp-propertyDependencies or propertyDependencies-beta1. It can even be included in a release that way. (The -beta* approach would let us iterate a keyword over multiple releases.) Then, once we're happy with how it works, we can transfer it to propertyDependencies to solidify that keyword.

Then we make implementing any exp-* or *-beta* keywords optional.

This gives us backward-/forward-compatibility because keywords never change (functionally), and it allows us to iterate on designs while giving implementors some kind of definition and users something to play around with.

[jdesrosiers]

@Relequestual

I think this shows we're still not super sure if what we're doing here is quite right, or if we need to re-think our approach.

I'm approaching this nearly from square one. Even for things we've previously had agreement on, I'm starting over. The only assumption I'm making here is that we all agree that we want compatible release. I wrote this up with respect for @Julian's view point and @awwright's similar view point. I don't think anything here eliminates any paths they or anyone else has expressed support for. I wrote the following in the PR description.

I included a super simple binary (stable or experimental) stability model. We heard at the last OCWM that not everyone is necessarily on board with including unstable behaviors in the spec. I figured defining it as a tool we can use doesn't hurt. If we decide we don't want to use that tool, we don't have to. Or, I can take it out.

I gave a super simple definition of what it means to be an experimental behavior, but defining isn't a decision that we will use that concept. If anyone is uncomfortable with approaching it that way, I'll take it out, but so far no one has asked me to remove it. I'm totally fine with removing it. Once this PR is merged, I will be opening additional issues to discuss the more controversial details and the first will probably be whether or not we include experimental behaviors in the specification or not.

[gregsdennis]

Perhaps for the purposes of this PR, experimental and deprecated features should not be mentioned, or at most, mentioned in a way that says we're thinking about it but gives no further detail.

Also, in conversations with a few others, this document seems to have a conflation of process vs policy. "Process" pertains to how we output documents (the "how, when, and how often"). "Policy" pertains to the contents of the documents and how we regard and respect those contents. I believe that there exists a desire to declare these things separately.

[handrews]

My position is fundamentally the same as it was a month ago: Merging a process(/policy) document is not what we need right now. We need to be discussing individual aspects of all of this in separate issues.

Regarding this iteration, two things are major concerns:

• Stable-by-default would lock in everything that we do not think to explicitly enumerate. That is not a viable approach (either initially or in the future).
• Deeming "experimental" features to be optional to implement, and labeling them with a name like "experimental" that discourages use, is not a viable path to getting the usage and feedback that we need to move those features forward.

These are the most substantive points in the document. Without them, it's less a document and more a placeholder template, which does not address any urgent need.

On complex changes, we have always worked first in issues so that we sort out each individual concept without tying them all together, and without getting hung up on wording. We need to identify the most important topics and open individual issues to discuss them, including identifying the problems each one solves. When we have agreement on which topics are necessary and how we want to handle them, we can then worry about how to word one or more documents to make those decisions official.

[jdesrosiers]

@gregsdennis

Perhaps for the purposes of this PR, experimental and deprecated features should not be mentioned

Ok. I'll do that.

"Policy" pertains to the contents of the documents and how we regard and respect those contents.

I'm not entirely clear what distinction you're making here. Can you elaborate? Specifically, what parts things would you consider don't belong in this document?

[jdesrosiers]

@handrews

On complex changes, we have always worked first in issues so that we sort out each individual concept

That's exactly what I'm trying to do. The point of this PR is to identify some small kernel of a foundation that we all agree on and iterate from there. I'm trying to avoid doing this big-design-up-front-style where we have to figure out all the details before we can make any progress. All of these issues are interconnected. There's going to have to be some degree of leaving some details undecided if we want to avoid having to decided everything before we can make any progress.

Regarding this iteration, two things are major concerns:

That's useful feedback, thank you. I'll remove those things and we can discuss them separately.

These are the most substantive points in the document. Without them, it's less a document and more a placeholder template, which does not address any urgent need.

I disagree. The critical thing here is defining that we want to start having compatible releases. I think that's the one thing everyone agrees on and I don't think we can have the other discussions without that context. I think we can create a minimal definition of compatible releases without deciding if the spec is stable by default, or whether unstable behaviors should be required, or what we call unstable behaviors.

[handrews]

@jdesrosiers what is it that we need to do right now that we cannot do without merging a document? This document does not say anything that hasn't been said in the ADR or earlier discussions.

[jdesrosiers]

@handrews This gives us a foundation to build on. I expect that we will discuss issues separately and add to this foundation as details are agreed on. It needs to exist before we can add to it, so why not merge the foundation now?

This effort serves another purpose as well. It's bring to light areas where we aren't in agreement. Whether we merge it or not, we're learning what needs further discussion just by working toward something we can merge.

[handrews]

@jdesrosiers I want to be clear that I'm not dismissing the value of what you're trying to do here, but I am uncomfortable with the form and find myself unable to work with it.

I've stated repeatedly from the first discussion on the SDLC that I think that the scope is too broad, that there are too many disparate things involved, and that the discussion of it all is difficult to work with and follow. You keep asking me to go with it and things will be figured out later, which I had hoped meant that you heard what I was saying and would break up later stages. It's certainly valid to want to start with a wide-ranging discussion even if it is not what I would have done or would have preferred.

But we're now on round four, and we skipped the necessary consensus-building on the details and went straight to wording. Even though we do not have consensus on the scope of the document or many of the most important points involved. And now here's another giant sprawling multi-threaded discussion of disparate topics that I'm trying to return to after the holidays and just can't.

It is not simply about removing the "controversial" points. As we've gone from discussion to ADR to larger process document to minimal process document, it has turned out that I missed things in the giant discussions that made it look like I'd agreed to things I did not agree to. And it has turned out that you meant different things by some points than I thought you did. I don't mean that in a malicious way, this has happened many times to all of us, whether with the spec or other things.

I am not comfortable merging any wording in a document at this time. There is no foundation here that isn't already documented in the ADR well enough for us to build on it. Beyond that, we do not have consensus on the important aspects. I am not even convinced at this point that we all agree on what it means to "start having compatible releases." So I'm not comfortable putting phrases like that in a document when I don't think we all hear the same meaning. That is just asking for trouble down the line when one of us objects to the meaning that you had in mind.

I've been on the other side of that dynamic when one of the rest of you has had a radically different interpretation of specification text than what I meant when I wrote it. It's awful. Best case scenario I can go look at old discussions and find clear support for my intended meaning. Otherwise it's just an argument of opinion and those are always hard.

We don't have the necessary discussions in place to support the best case scenario here. This PR is not the right forum for it, which is why I have not replied to any other threads. I am worn out by these mega-discussions.

Let's work the way we've always worked. Goodness knows I tried at times to shove too much into the spec at once. Many times I had to back down and break things up, which was good. Some of the times when I still pushed too hard it caused problems later. We usually have to make mistakes like that to learn, but let's not make ourselves repeat that lesson.

Please open individual issues for each important topic (or use ones @gregsdennis opened a while back if they fit) so we can each follow the parts in which we are most interested. Please work to build consensus within the team for enough of the topics that we can all confidently move forward, and then open PRs where the only thing we need to discuss is whether the wording captures the decisions from the issues. We may at that point open a PR for a document that looks like this, or we may end up doing something else- for example, separate process and policy documents (and it will be so much easier to discuss the difference between those topic-by-topic).

Building a strong consensus in issues and then using PRs only to translate that consensus into formal language is the process that has always worked best for JSON Schema. All I'm asking here is that we return to that.

[karenetheridge]

• Stable-by-default would lock in everything that we do not think to explicitly enumerate. That is not a viable approach (either initially or in the future).
• Deeming "experimental" features to be optional to implement, and labeling them with a name like "experimental" that discourages use, is not a viable path to getting the usage and feedback that we need to move those features forward.

I strongly agree. Experimental does not mean optional, nor does unstable. It can mean anything from "we're not entirely sold on if this is a good idea yet, but it doesn't hurt anything else to add it, so let's see what the community thinks; we may change it or remove it entirely in a subsequent release" to "we think this is a good idea, but we're not quite sure if we're done iterating on it yet", to "we now think this isn't so great, but we haven't come up with a good replacement yet, so it's still here for now".

Let's think through an example: the $dynamicRef keyword. This originated in draft2020-12, but bears a strong relation to $recursiveRef in draft2019-09, where it was created to solve a known class of evaluation problems. The problems solved by this keyword aren't going away, so we know we're not going to deprecate or remove $dynamicRef. However, it was changed between 2019-09 and 2020-12, and it is changing again (although in a smaller way) in 2023-XX. Can we declare this "stable" in 2023-XX? I don't think so -- we might find it desirable to make another small tweak to this keyword's functionality. I don't think we should be prepared to declare this keyword "stable" until it's gone at least one release without any sort of change. Now, at that point, we can even retroactively go back and declare the keyword stable in the previous release (i.e. after that release its functionality didn't change, even though we didn't know that at the time).

For prior art on "experimental", "deprecated" and "stable" features, we can look at what Perl does -- some experimental features were/are available only via pragmata, and for some of these features, a later release of the language either declared the feature "stable" (no longer hidden behind a pragma; stability might have been achieved at an earlier point, which we can identify after-the-fact), or "deprecated" (and then subsequently removed in a later release).

• https://perldoc.perl.org/experimental
• https://perldoc.perl.org/perldeprecation
• stable.pm: experimental.pm but only when safe Dual-Life/experimental#12 <-- adds the "stable" declaration to some features in certain versions which were still experimental but did not change after that point in time, and later on became non-experimental

[gregsdennis]

In regard to the conflation of process/policy, I suggest the following:

• we focus on completing the charter discussion/proposal first.
• we then create a set of policies that help fulfill that charter (e.g. compatibility guarantees and other promises)
• finally, we can create a process that ensure we adhere to those policies (e.g. publication procedures and the mechanisms by which we implement compatibility guarantees)

I think this will help isolate the differences and let us focus on each.

[gregsdennis]

Is this relevant anymore since the time for an interim release is basically past? I think we've decided to go a different direction and work on some other blockers.

[jdesrosiers]

Is this relevant anymore since the time for an interim release is basically past?

Either way, this PR has too much baggage. I'll close it for now.