|
| 1 | +# Extract Unstable Features for Initial Release |
| 2 | + |
| 3 | +* Status: accepted |
| 4 | +* Deciders: @gregsdennis @jdesrosiers @bhutton |
| 5 | +* Date: 2024-05-08 |
| 6 | + |
| 7 | +Technical Story: |
| 8 | + |
| 9 | +@gregsdennis [proposed](https://github.com/json-schema-org/json-schema-spec/issues/1443#issuecomment-2099427543) that an ADR be created to document that unstable features be extracted before the stable release. |
| 10 | + |
| 11 | +Also the [SDLC proposal](https://github.com/orgs/json-schema-org/discussions/671) which lists features that need to be put into the proposal process. |
| 12 | + |
| 13 | +## Context and Problem Statement |
| 14 | + |
| 15 | +In creating a stable spec release, it's important that all included features are well-developed and their behaviors are finalized. As such, the following features will be extracted before the stable release. |
| 16 | + |
| 17 | +- `$vocabulary` - This feature is still in development. |
| 18 | +- Output formats - This feature is being extracted to its own spec anyway. (See [PR](https://github.com/json-schema-org/json-schema-spec/pull/1429) for more info and link to discussion.) |
| 19 | +- `propertyDependencies` - This feature is not technically in the spec and should go through the proposal process. |
| 20 | + |
| 21 | +## Decision Drivers <!-- optional --> |
| 22 | + |
| 23 | +We can't publish a stable spec that contains unstable features. Thus we need to remove them. |
| 24 | + |
| 25 | +## Considered Options |
| 26 | + |
| 27 | +1. Extract unfinished features and put them through the proposal process. |
| 28 | +2. Complete the features before releasing the spec. |
| 29 | + |
| 30 | +## Decision Outcome |
| 31 | + |
| 32 | +Chosen option: Extract unfinished features and put them through the proposal process. |
| 33 | + |
| 34 | +This allows us to release a stable version of the specification while continuing to develop these features. |
| 35 | + |
| 36 | +### Positive Consequences <!-- optional --> |
| 37 | + |
| 38 | +* We can release a spec earlier that fulfills our users' needs. |
| 39 | +* We can continue to develop these features. |
| 40 | + |
| 41 | +### Negative Consequences <!-- optional --> |
| 42 | + |
| 43 | +* These feature will be considered experimental until their proposals are accepted. This may be a hindrance to adoption. |
| 44 | + |
| 45 | +## Pros and Cons of the Options <!-- optional --> |
| 46 | + |
| 47 | +### Extract unfinished features and put them through the proposal process |
| 48 | + |
| 49 | +* Good, because we can release a spec earlier that fulfills our users' needs. |
| 50 | +* Good, because we can continue to develop these features. |
| 51 | +* Bad, because these features are experimental now. |
| 52 | + |
| 53 | +### Complete the features before releasing the spec |
| 54 | + |
| 55 | +* Good, because the features will be ready to use when the spec releases. |
| 56 | +* Bad, because the spec may not release if we can't finalize the features. |
0 commit comments