Update new struct versioning rule (#5429)

If I understand this document, any change to a struct that invalidates its layout in other versioning bubbles would be considered a breaking change. I believe this would include adding or removing a field or changing the type of a field in an internal struct if that struct is included as a (possible non-public) field in a public struct; just because a struct is internal doesn't mean it's not subject to the new versioning rule.

diff --git a/Documentation/botr/readytorun-overview.md b/Documentation/botr/readytorun-overview.md
index ae1f76c..9e9f334 100644 (file)
--- a/Documentation/botr/readytorun-overview.md
+++ b/Documentation/botr/readytorun-overview.md
@@ -83,7 +83,7 @@ These are problematic because value classes are valuable precisely _because_ the
 
 Thus this proposal does _not_ suggest that we try to solve the problem of having version resilience in the presence of layout changes to value types. Instead we suggest creating a new compatibility rule:
 
-**It is a breaking change to change the number or type of any (including private) fields of a public value type (struct). However if the struct is non-public (that is internal) then the restriction does not apply.**
+**It is a breaking change to change the number or type of any (including private) fields of a public value type (struct). However if the struct is non-public (that is internal), and not reachable from any nesting of value type fields in any public value type, then the restriction does not apply.**
  
 This is a compatibility that is not present for CIL. All other changes allowed by CIL can be allowed by native code without prohibitive penalty. In particular the following changes are allowed:
 
@@ -332,4 +332,4 @@ Another important observation is that `MethodTable` contains other very frequent
 
 # Current State
 
-The design and implementation is a work in progress under code name ReadyToRun (`FEATURE_READYTORUN`). RyuJIT is used as the code generator to produce the ReadyToRun images currently.
\ No newline at end of file
+The design and implementation is a work in progress under code name ReadyToRun (`FEATURE_READYTORUN`). RyuJIT is used as the code generator to produce the ReadyToRun images currently.