<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <style type="text/css"> /* <![CDATA[ */ @import "branding/css/tigris.css"; @import "branding/css/inst.css"; /* ]]> */</style> <link rel="stylesheet" type="text/css" media="print" href="branding/css/print.css"/> <script type="text/javascript" src="branding/scripts/tigris.js"></script> <title>Subversion Roadmap</title> </head> <body> <div class="app"> <h1 style="text-align: center">Subversion Roadmap</h1> <div class="h2" id="upcoming-releases" title="upcoming-releases"> <h2>Upcoming Releases</h2> <p>This is a <em>preliminary</em> timetable for the next few upcoming releases. As noted above, we do not guarantee that a specific feature will be in a given release, or that a release will be published on a particular schedule. The following chart is more of a guideline for the developers to help ensure more timely releases, and is quite mutable.</p> <table border="1" class="sborder" style="margin-left: auto; margin-right: auto;"> <tr> <th>Date</th> <th>Task</th> <th>Notes</th> </tr> <tr> <td>January 28, 2009</td> <td>Branch 1.6.x, roll 1.6.0-rc1</td> <td></td> </tr> <tr> <td>February 25, 2009</td> <td>Roll 1.5.6 release</td> <td>This date may change, depending on the 1.6.0 release schedule.</td> </tr> <tr> <td>Late February 2009</td> <td>Roll 1.6.0 tarball</td> <td></td> </tr> </table> <p>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 typical nomination/review/vote/merge process in the couple of days prior to the release, and it also allows some time for committers to test and sign the tarball before the weekend hits. The release is finalized and announced shortly after all the signatures are collected. See the <a href="release-process.html">release process</a> for more information.</p> </div> <div class="h2" id="release-planning" title="release-planning"> <h2>How We Plan Releases</h2> <p>Subversion uses a compromise between time-driven and feature-driven release planning. We schedule the next release for an approximate date (very approximate), and make sure it contains one or more new features or other significant differentiators, but we don't say exactly what those new features will be. This is because we're always working on several things at once, and we want to give each new feature time to mature. Especially given the decentralized nature of open-source development, we're wary of forcing technical discussions to premature consensus. At the same time, it's good for the project to have regular releases, so we try to keep to a schedule and to have <i>something</i> ready to roll out when the release date comes along.</p> <p>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. For more information about Subversion's release numbering and compatibility policies, see the section entitled <i>"Release numbering, compatibility, and deprecation"</i> in the <a href="hacking.html">Hacker's Guide to Subversion</a>.</p> </div> <div class="h2" id="upcoming-features" title="upcoming-features"> <h2>Upcoming Features</h2> <p>We try to have at least one or two new features under active development at any given time, but we generally don't rush a feature to get it into a release. The flexibly time-driven model <a href="#release-planning">described above</a> means there's never a long wait between releases, which in turn means less pressure to cram a feature into whatever release happens to be going out the door next. Our main source of ideas is our users: we watch the <a href="mailto:users@subversion.tigris.org" >users@subversion.tigris.org</a> mailing list, the <a href="irc://irc.freenode.net/#svn">#svn IRC channel</a>, and the <a href="issue-tracker.html">issue tracker</a> to see what people are saying, and base our priorities on that, though we may sometimes grab low-hanging fruit along the way.</p> <p>Below are new features currently under discussion and design, as extracted from the ever-changing consensus of the Subversion developer community. Because this is a volunteer open-source project, it's hard to predict exact dates or timetables for these new features. At most, we can express dependencies and predict the order in which things will be worked on. <em>Just because a feature is listed for a particular release does not guarantee that it will be in that release.</em> Hard feature lists don't actually get set until the <a href="release-process.html#release-branches">release branch</a> is created. The best way to track development is to <a href="/servlets/ProjectMailingListList">subscribe</a> to the development mailing list, <a href="mailto:dev@subversion.tigris.org" >dev@subversion.tigris.org</a>.</p> <ul> <li><b>Medium-term Goals:</b> <ul> <li>1.6 <ul> <li>Augmented diff representation (svnpatch)</li> <li>Python C-types bindings</li> </ul> </li> <li>Eventually <ul> <li>Improved rename support (see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=898" >issue #898</a>)</li> <li>Log message templates (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=325870" >discussion thread</a>)</li> <li>Repository-defined autoprops (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=329707" >discussion thread</a>)</li> <li>Inherited properties (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=326933" >discussion thread</a>)</li> <li>Rewrite the working-copy library to feature centralized metadata storage</li> </ul> </li> </ul> </li> <li><b>Long-term Goals</b> <ul> <li><p>hybrid distributed/centralized VC model</p></li> <li><p>repository-level ACLs</p></li> <li><p>broader WebDAV/deltaV compatibility</p></li> <li><p>improved pluggable client-side diff (see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2044">issue #2044</a>)</p></li> <li><p>progressive multi-lingual support</p></li> <li><p>SQL repository back-end?</p></li> </ul> </li> </ul> </div> <div class="h2" id="past-releases" title="past-releases"> <h2>Past Releases</h2> <p>For information about past releases, see the <a href="release-history.html">release history</a>.</p> <p>To see a summary of the major changes in each Subversion release, read over the <a href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file.</p> </div> </div> </body> </html>