At the moment, there is no timetable for the next release. Dates, feature deliverables, and even version numbers found in this list are all subject to change (and become increasingly more speculative the further out we attempt to project). Fortunately, the same dynamics that allow features to fall out of releases or for release dates to slip also allow for feature and release acceleration. That's the nature of open-source, community-driven software projects (and we think it's a great thing). So if you don't like what you see here, do something about it: your contributions are always welcome!
We try to roll releases on Wednesdays. Like most of the other information on this page, the day we roll isn't a hard-and-fast rule, but it is something that has been useful in the past. Rolling mid-week gives us enough time for the release preparation process in the couple of days prior to the release, and some time before the weekend for validation of the release tarballs. The release is finalized and announced as soon after the completion of the validation process as possible. See the documentation of our release process for more information.
Subversion has two types of releases: regular releases are intended to deliver new features more quickly, while LTS releases are intended to provide stability over longer periods.
The two types releases differ in their support lifetime:
Regular releases are supported for six months from the date of their initial release. For instance, 1.11.x was supported until six months after the announcement of 1.11.0. A regular release may be used to get new features out sooner without having to support a particular release for an extended period of time, to make feature development more appealing, rewarding and faster for both the contributors and the users.
LTS releases are supported for four years from the date of their initial release. For instance, 1.14.x will be supported until four years after the announcement of 1.14.0.
LTS releases are supported until three months after the release of the next LTS.
The previous two guarantees cumulate: for an LTS release line to be declared end-of-life (EOL), it has to both have been first released over four years before and have been supported in parallel to a newer LTS release line for at least three months.
For instance, assume 1.42.0 is released on 2042-07-01 and 1.42 is declared an LTS line. In this case, 1.42 will be supported at least until 2046-06-30 (with no ifs, buts, or maybes). Furthermore, it is expected that a newer LTS release (1.43.0, 1.44.0, etc.) will be made before 2046-04-01, leaving three months for upgrading installations. In case no newer LTS release is made until, say, 2048-01-01, the lifetime of 1.42 will automatically be extended until 2048-03-31.
At any given time there will be at least one supported LTS release. The most current LTS release will be supported with general backports and any older release(s) will receive high priority fixes.
During the support period, we commit to providing updates that fix high priority issues such as security and data loss or corruption. We may also sometimes fix other issues as appropriate to the emphasis of each release.
In this context, "release" means an increment of the minor release number, which is the middle number in our three-component system. Thus, 1.2.0, 1.3.0, and 1.4.0 are successive minor releases in the "1.x" line, whereas 1.1.1, 1.1.2, and 1.1.3 are successive patch (bugfix) releases in the "1.1.x" line. We don't schedule patch releases far in advance, we just put them out when we feel enough bugfixes have accumulated to warrant it. Major new releases, such as Subversion 2.0, will probably be done much like the minor releases, just with more planning around the exact features.
To date, every release since 1.0 has been LTS, with the exception of 1.11, 1.12, and 1.13 which were regular.
For more information about Subversion's release numbering and compatibility policies, see the section entitled "Release numbering, compatibility, and deprecation" in the Subversion Community Guide.
The following is a list of "most wanted" features/enhancements we've identified as important and achievable, in no particular order, along with the chain of dependendies we believe exist and stand in the way of our delivering these items in Subversion. This is not an exhaustive list! It merely represents some of the "the big ones" — big in impact, and probably big in development cost.
OUT OF DATE (written in 2010, only minor updates since then)
Feature / Enhancement | Dependencies | Target Release | Issue(s) |
---|---|---|---|
Rename Tracking | Ev2?, FS-NG? | 2.0? | 898, 3630 |
Improved Merging | 1.x? | ||
Improved Tree Conflict Handling | 1.10 | ||
Control of Strictness for Conflicts | 1.x? | 4405 | |
Enterprise Authentication Mechanisms | 1.x? | 3629 | |
Log Message Templates | Repository-dictated Configuration | 1.x? | 1973 |
Shelve | 1.10 ... | 3625 | |
Checkpoint | 1.11 ... | 3626 | |
Flexible Repository Storage (FS-NG) | 2.0? | ||
Obliterate | FS-NG | 2.0? | 516 |
Forward History Searching | FS-NG? | 2.0? | 3627 |
Draft release notes are added to the release notes index some time before each release is published.
For information about past releases, see the release notes.