@@ -97,7 +97,7 @@ you will never need to change it just to keep up with changes to JSON Schema.
9797This is also better for implementers because they don't have to maintain
9898separate code with different semantics in different versions. They just need to
9999code for the current release and they will automatically have support for past
100- releases.
100+ releases (not including "draft" releases) .
101101
102102### Option 1 - TC-39 Inspired
103103The two things that make this option stand out are the stability model governing
@@ -131,11 +131,12 @@ how likely a feature is to change in the future. Whether they prefer to stick
131131with stable features or want to use a new keyword, users have the information
132132they need to make that decision.
133133
134- The downside of the stability model is that it presents a very high barrier for
135- a feature to make it into a stable status. It would typically take two years for
136- a feature to reach stability which could be a long time to wait for users who
137- need to stick to the stable feature set but could benefit greatly from a new
138- feature.
134+ The stability model sets a very high barrier for a feature to make it into
135+ stable status. This is on purpose so we can be very sure features won't change
136+ once they are stable, but this process can take a long time. It would typically
137+ take two years for a feature to reach stability which could be a long time to
138+ wait for users who need to stick to the stable feature set but could benefit
139+ greatly from a new feature.
139140
140141### Option 2 - IETF Inspired
141142The benefit of this approach is that it's compatible with the IETF process
0 commit comments