You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Clarifications about implementation and documentation review
Per discussion with Holly:
- remove "generally"
- explicitly include user docs as not covered by evolution
Also fix an oversight in the semantic newline conversion.
Copy file name to clipboardExpand all lines: process.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,13 +10,15 @@ The Swift evolution process applies to all design changes to specific aspects of
10
10
This includes the Swift language, its standard library and certain other core libraries, and the interfaces of core tools such as the Swift package manager.
11
11
The complete list is given [below](#evolution-areas).
12
12
13
-
The evolution process applies only to the design of features, not their implementation.
14
-
Implementation work in the Swift project is generally open-source and subject to the normal code review process; see [Contributing to Swift](https://www.swift.org/contributing/).
13
+
The evolution process applies only to the design of features.
14
+
Neither the implementation of the feature nor the user documentation for it require evolution review.
15
+
Implementation and documentation work in the Swift project is open-source and subject to the normal code review process; see [Contributing to Swift](https://www.swift.org/contributing/).
15
16
Changes such as bug fixes, optimizations, and diagnostic improvements can be contributed at any time.
16
17
Implementation review is generally completely independent from the design review performed by the Swift evolution process.
17
18
However, there is one important exception: patches that would change a design covered by the evolution process should not be merged without the approval of the appropriate evolution workgroup.
18
19
This may include fixing bugs, if the bug allows additional things to be expressed or changes the user-visible behavior of a feature.
19
-
Bugs in features that have not yet been officially released can be freely fixed. Implementors should check with the appropriate evolution workgroup if they're uncertain what to do.
20
+
Bugs in features that have not yet been officially released can be freely fixed.
21
+
Implementors should check with the appropriate evolution workgroup if they're uncertain what to do.
20
22
21
23
The evolution process does not cover the design of experimental features, which can be added, changed, or removed at any time using the normal code review process.
22
24
Implementations should take steps to prevent the accidental use of experimental features, such as by enabling them only when an explicitly experimental command line flag is passed to the tool.
0 commit comments