source encoding: update the target version (v5.38, not 36)

Author: rjbs

rfcs/rfc0007.md

@@ -24,12 +24,12 @@ appear to do so, but will behave correctly when printed to a UTF-8 terminal.
 All these behaviors can be explained, but can still surprise both beginner and
 expert.  To eliminate surprise at runtime, this proposal intends to give the
 programmer a means to declare that non-ASCII bytes are a compile-time error.
-It also proposes to make that declaration implicit in "use v5.36" and later
+It also proposes to make that declaration implicit in "use v5.38" and later
 version declarations.
 
 ## Rationale
 
-The biggest goal here is to make "use v5.36" sufficient to avoid runtime
+The biggest goal here is to make "use v5.38" sufficient to avoid runtime
 confusion falling out of non-ASCII source.  Given the complexity of "just make
 it all Unicode and UTF-8", the goal is to alert the programmer that they've
 used non-ASCII in their source without declaring that they've thought about it.
@@ -53,7 +53,7 @@ be raised when reading a non-ASCII byte in the source.
 `no source::encoding` will return to the default behavior of reading bytes into
 codepoints.
 
-`use v5.36` (and later) will implicitly set the source encoding to ASCII.
+`use v5.38` (and later) will implicitly set the source encoding to ASCII.
 Using the feature bundle will have no effect on source encoding.
 
 ## Backwards Compatibility
@@ -108,7 +108,7 @@ behavior to prefer UTF-8 to ASCII.
 
 ## Rejected Ideas
 
-The first proposal to eliminate non-ASCII source footguns was to have use v5.36
+The first proposal to eliminate non-ASCII source footguns was to have use v5.38
 enable the utf8 pragma.  The objection raised was that this would lead to new
 kinds of confusion related to decoded (text) strings being printed to
 filehandles with no encoding layer.  Although this is explainable behavior, the