www/roadmap.html - subversion - Git at Google

 <!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>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 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="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.  <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.5
       <ul>
         <li>Merge tracking: tracking of merge history (see
         <a href="merge-tracking/">info</a>)</li>

         <li>Sparsely populated checkouts (full API and basic
         command-line support coming in 1.5)</li>
       </ul>
     </li>

     <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&amp;by=thread&amp;from=325870"
         >discussion thread</a>)</li>

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

         <li>Inherited properties (see <a href="http://subversion.tigris.org/servlets/BrowseList?list=dev&amp;by=thread&amp;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="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>
	<!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>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 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="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. <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.5
	<ul>
	<li>Merge tracking: tracking of merge history (see
	<a href="merge-tracking/">info</a>)</li>

	<li>Sparsely populated checkouts (full API and basic
	command-line support coming in 1.5)</li>
	</ul>
	</li>

	<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="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>