www/roadmap.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<style type="text/css"> /* <![CDATA[ */
  @import "tigris-branding/css/tigris.css";
  @import "tigris-branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
  href="tigris-branding/css/print.css"/>
<script type="text/javascript" src="tigris-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>For a schedule of upcoming releases, please see the <a
href="project_status.html">project status</a> page.</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 each release for a certain date, and
make sure a release 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="http://svn.collab.net/repos/svn/trunk/HACKING">the HACKING
file</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="project_issues.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.  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><p>Log message templates  (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&amp;by=thread&amp;from=325870"
    >discussion thread</a>)</p>
    </li>

    <li><p>Repository-defined autoprops (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&amp;by=thread&amp;from=329707"
    >discussion thread</a>)</p>
    </li>

    <li><p>Inherited properties (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&amp;by=thread&amp;from=326933"
    >discussion thread</a>)</p>
    </li>

    <li><p>Improved rename support (see <a
    href="http://subversion.tigris.org/issues/show_bug.cgi?id=898"
    >issue #898</a>)</p>
    </li>

    <li><p>Merge tracking (see <a
    href="http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt"
    >notes</a>)</p>
    </li>
  </ul>
</li>

<li><b>Long-term Goals</b>
  <ul>
    <li><p>repository-level ACLs</p></li>
    <li><p>SQL repository back-end?</p></li>
    <li><p>rewrite of working-copy library</p></li>
    <li><p>broader WebDAV/deltaV compatibility</p></li>
    <li><p>pluggable client-side diff programs</p></li>
    <li><p>progressive multi-lingual support</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="project_status.html">project status</a> page.</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>