swift-evolution: the proposal repository that explains where Swift goes next

A repository of proposals, not of Swift code

The first line of the README after the title is a link, and the description says what this is: the repository tracks the ongoing evolution of the Swift programming language, standard library and package manager. Every entry in the tree confirms it. There is no `Sources` directory, no build manifest and no module file. What there is, is `proposals/`, `proposal-templates/`, `policies/`, `process.md`, `releases/` and `visions/`.

So this is governance as source code, in the literal sense that the rules are reviewable in the same place as the changes. If you want to know how a language change gets accepted, `process.md` and the `policies/` directory are the answer, and if you want to know what is being considered, `proposals/` and `commonly_proposed.md` are where to look.

The primary language of the repository is listed as Markdown, which sounds like a throwaway detail until you realise there is nothing else it could be. The output of this project is a set of documents that other people argue over, which is exactly what Markdown is for.

What the release table says about the current cadence

The README is mostly a table with three columns: version, announced date and released date. It runs from Swift 2.2 released in March 2016 up to Swift 6.4 released on 2026-09-15. Each version links to the forum post that announced it and the blog post that shipped it, so the table doubles as an index into the process documentation.

The dates tell you that the pre-6.0 line ran on roughly a nine-month rhythm, with Swift 5.0 released 2019-03-25 and Swift 5.10 released 2024-03-05. The 6.x line is faster: Swift 6.0 on 2024-09-17, then 6.1 on 2025-03-31, 6.2 on 2025-09-15, 6.3 on 2026-03-24 and 6.4 on 2026-09-15. That is a six-month train, and the gap between announced and released has stayed close to six months every time, which means the announcement is a real schedule commitment rather than a hint.

The gap between announcement and release is also the window in which proposals land. A proposal accepted for a version announced on a given date will appear in the release roughly six months later, which is the practical reason to read this repository rather than waiting for release notes.

Policies, templates and the shape of a review

The `policies/` directory is the part that makes this more than a suggestion box. Language changes go through a structured review with stated criteria, and the policies are committed alongside the proposals so the rules cannot shift quietly between rounds. `proposal-templates/` provides the shape a proposal is expected to take, which matters more than it sounds: a proposal that does not follow the template is slow to review because reviewers have to reconstruct what is being asked.

`process.md` sits at the repository root as the entry point for the whole sequence, from a pitch through to a shipped change. `visions/` holds longer-term direction documents, and `CONTRIBUTING.md` covers the practical side of contributing, which for a language repository usually includes signing a contributor agreement or agreeing to terms.

`releases/` is the directory to check when you want to know which proposals are queued for a specific version. Between `process.md`, `policies/` and `releases/`, a reader can reconstruct the full path from idea to shipped feature without leaving the repository.

commonly_proposed.md and the proposals still waiting

One file at the root has a name that does the explaining: `commonly_proposed.md`. It exists so that proposals for the same idea, which otherwise arrive as separate documents and get reviewed separately, can be pointed at one another. A macro or metatype feature, or a syntax addition that people keep asking for, is the kind of thing that would otherwise spawn a dozen near-identical files.

The proposals directory holds the individual documents, each one typically naming the authors, the motivation, the detailed design and the review status. Because they are plain files, you can read them in a browser, diff them, or grep across years of language design decisions, which is a genuinely useful capability when you are trying to understand why the language is the way it is.

The distinction between `proposals/` and `commonly_proposed.md` is the useful one to carry away. A file in `proposals/` is a specific, argued change under review. A heading in `commonly_proposed.md` is an idea with enough demand that it is worth coordinating before anyone writes the full design.

Where the README points, and the one inconsistency

The README links out three ways. The canonical site is at swift.org/swift-evolution, the goals section points to a forum post titled Swift Language focus areas heading into 2025, and the changelog link points at `github.com/apple/swift`.

That last one is an inconsistency worth naming rather than smoothing over. The repository lives under the `swiftlang` organisation, while the changelog it points readers to sits under `apple`. Both links are in the README as published, so the changelog for the compiler itself is being served from the older organisation path. If you are looking for the authoritative list of what changed in a given version, follow the link and expect to be on a different repository than this one.

The focus areas link is dated 2025 while the release table runs into 2026, which suggests the goals section has not been updated as often as the table. Everything specific to a version, however, is current: Swift 6.4 is listed as released on 2026-09-15, and the last push to this repository was on 2026-09-21, days after that release.

Published as a website as much as a repository

Two files at the root explain how this is served: `.nojekyll` and `404.html`, alongside a `.gitattributes` file. GitHub Pages serves the repository as a static site, and the custom 404 page is what makes that reading experience acceptable rather than broken when someone follows a stale link to a proposal.

That detail matters for how you should treat the repository. It is written to be read in a browser, not only in a clone, so the folder names are navigation labels: proposals, policies, releases, visions. There is no build to run and nothing to install, which is unusual to say about a repository in the Swift ecosystem and matches its content.

The licence is Apache 2.0, recorded in `LICENSE.txt`, which is the usual choice for specification and process documents because it allows anyone to reuse the text. There are no releases published on the repository itself, which is consistent with a project whose outputs are proposals rather than binaries.

Editorial conclusion

This repository is the right bookmark for anyone who plans work against future Swift versions, because it shows proposals while they are still drafts rather than after they ship. Two limits are worth stating plainly. It contains no code, so nothing here compiles or runs, and it publishes no GitHub releases, so the authoritative changelog lives in the compiler repository that the README links to. Start with `process.md` and `policies/`, then `commonly_proposed.md` if you are filing something new, and use the README release table to see that Swift 6.4 shipped on 2026-09-15 with the next version already announced.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. swiftlang/swift-evolution on GitHub