This section provides some expectations as to what features might be provided in future major versions. It is not a guarantee of a feature landing in a particular version, but it yields some sense of what core developers have some focus on. The most up-to-date version of this document will always be in the git repository.

The sub-sections that follow only outline those release lines that expect to include significant new features. Other release lines may continue to be active with maintenance work and bug fixes, but won’t be listed here. The items listed in each release line represent unreleased changes only. Once an official release is made for a line, the roadmap items are removed with new items taking their place as they are planned. The release line is removed from the roadmap completely when it is no longer maintained.

This section tracks and details future ideas. While the dev list is the primary place to talk about new ideas, complex topics can be initiated from and/or promoted to this space. While it is fine to include smaller bits of content directly in future/index.asciidoc, longer, more developed proposals and ideas would be better added as individual asciidoc files which would then be included as links to the GitHub repository where they will be viewable in a formatted state. In this way, this section is more just a list of links to proposals rather than an expansion of text. Proposals should be named according to this pattern "proposal-<name>-<number>" where the "name" is just a logical title to help identify the proposal and the "number" is the incremented proposal count.

The general structure of a proposal is fairly open but should include an initial "Status" section which would describe the current state of the proposal. A new proposal would likely hae a status like "Open for discussion". From there, the proposal should include something about the "motivation" for the change which describes a bit about what the issue is and why a change is needed. Finally, it should explain the details of the change itself.

At this stage, the proposal can then be submitted as a pull request for comment. As part of that pull request, the proposal should be added to the table below. Proposals always target the master branch.

The table below lists various proposals and their disposition. The Targets column identifies the release or releases to which the proposal applies and the Resolved column helps clarify the state of the proposal itself. Generally speaking, the proposal is "resolved" when the core tenants of its contents are established. For some proposals that might mean "fully implemented", but it might also mean "scheduled and scoped with open issues set aside". In that sense, the meaning is somewhat subjective. Consulting the "Status" section of the proposal itself will provide the complete story.