1 <!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN"
2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html xmlns=
"http://www.w3.org/1999/xhtml">
5 <style type=
"text/css"> /* <![CDATA[ */
6 @import
"branding/css/tigris.css";
7 @import
"branding/css/inst.css";
9 <link rel=
"stylesheet" type=
"text/css" media=
"print"
10 href=
"branding/css/print.css"/>
11 <script type=
"text/javascript" src=
"branding/scripts/tigris.js"></script>
12 <title>Subversion Roadmap
</title>
18 <h1 style=
"text-align: center">Subversion Roadmap
</h1>
20 <div class=
"h2" id=
"upcoming-releases" title=
"upcoming-releases">
21 <h2>Upcoming Releases
</h2>
23 <p>For a schedule of upcoming releases, please see the
<a
24 href=
"project_status.html">project status
</a> page.
</p>
28 <div class=
"h2" id=
"release-planning" title=
"release-planning">
29 <h2>How We Plan Releases
</h2>
31 <p>Subversion uses a compromise between time-driven and feature-driven
32 release planning. We schedule the next release for an approximate
33 date (very approximate), and make sure it contains one or more new
34 features or other significant differentiators, but we don't say
35 exactly what those new features will be. This is because we're always
36 working on several things at once, and we want to give each new
37 feature time to mature. Especially given the decentralized nature of
38 open-source development, we're wary of forcing technical discussions
39 to premature consensus. At the same time, it's good for the project
40 to have regular releases, so we try to keep to a schedule and to
41 have
<i>something
</i> ready to roll out when the release date comes
44 <p>In this context,
"release" means an increment of the minor release
45 number, which is the middle number in our three-component system.
46 Thus,
1.2.0,
1.3.0, and
1.4.0 are successive minor releases in the
47 "1.x" line, whereas
1.1.1,
1.1.2, and
1.1.3 are successive patch
48 (bugfix) releases in the
"1.1.x" line. We don't schedule patch
49 releases far in advance, we just put them out when we feel enough
50 bugfixes have accumulated to warrant it. Major new releases, such as
51 Subversion
2.0, will probably be done much like the minor releases,
52 just with more planning around the exact features. For more
53 information about Subversion's release numbering and compatibility
54 policies, see the section entitled
<i>"Release numbering,
55 compatibility, and deprecation"</i> in the
56 <a href=
"hacking.html">Hacker's Guide to Subversion
</a>.
</p>
60 <div class=
"h2" id=
"upcoming-features" title=
"upcoming-features">
61 <h2>Upcoming Features
</h2>
63 <p>We try to have at least one or two new features under active
64 development at any given time, but we generally don't rush a feature
65 to get it into a release. The flexibly time-driven model
<a
66 href=
"#release-planning">described above
</a> means there's never a
67 long wait between releases, which in turn means less pressure to cram
68 a feature into whatever release happens to be going out the door next.
69 Our main source of ideas is our users: we watch the
<a
70 href=
"mailto:users@subversion.tigris.org"
71 >users@subversion.tigris.org
</a> mailing list, the
<a
72 href=
"irc://irc.freenode.net/#svn">#svn IRC channel
</a>, and the
<a
73 href=
"project_issues.html">issue tracker
</a> to see what people are
74 saying, and base our priorities on that, though we may sometimes grab
75 low-hanging fruit along the way.
</p>
77 <p>Below are new features currently under discussion and design, as
78 extracted from the ever-changing consensus of the Subversion developer
79 community. Because this is a volunteer open-source project, it's hard
80 to predict exact dates or timetables for these new features. At most,
81 we can express dependencies and predict the order in which things will
82 be worked on.
<em>Just because a feature is listed for a particular
83 release does not guarantee that it will be in that release.
</em> Hard
84 feature lists don't actually get set until the
<a
85 href=
"release-process.html#release-branches">release branch
</a> is
86 created. The best way to track development is to
<a
87 href=
"/servlets/ProjectMailingListList">subscribe
</a> to the
88 development mailing list,
<a href=
"mailto:dev@subversion.tigris.org"
89 >dev@subversion.tigris.org
</a>.
</p>
93 <li><b>Medium-term Goals:
</b>
97 <li>Merge tracking: tracking of merge history (see
98 <a href=
"merge-tracking/">info
</a>)
</li>
100 <li>Sparsely populated checkouts (full API and basic
101 command-line support coming in
1.5)
</li>
107 <li>Augmented diff representation (svnpatch)
</li>
109 <li>Python C-types bindings
</li>
115 <li>Improved rename support (see
<a
116 href=
"http://subversion.tigris.org/issues/show_bug.cgi?id=898"
117 >issue #
898</a>)
</li>
119 <li>Log message templates (see
<a href=
"http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=325870"
120 >discussion thread
</a>)
</li>
122 <li>Repository-defined autoprops (see
<a href=
"http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=329707"
123 >discussion thread
</a>)
</li>
125 <li>Inherited properties (see
<a href=
"http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=326933"
126 >discussion thread
</a>)
</li>
128 <li>Rewrite the working-copy library to feature centralized metadata
135 <li><b>Long-term Goals
</b>
137 <li><p>hybrid distributed/centralized VC model
</p></li>
138 <li><p>repository-level ACLs
</p></li>
139 <li><p>broader WebDAV/deltaV compatibility
</p></li>
140 <li><p>improved pluggable client-side diff (see
<a
141 href=
"http://subversion.tigris.org/issues/show_bug.cgi?id=2044">issue
143 <li><p>progressive multi-lingual support
</p></li>
144 <li><p>SQL repository back-end?
</p></li>
152 <div class=
"h2" id=
"past-releases" title=
"past-releases">
153 <h2>Past Releases
</h2>
155 <p>For information about past releases, see the
<a
156 href=
"project_status.html">project status
</a> page.
</p>
158 <p>To see a summary of the major changes in each Subversion release,
160 href=
"http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES
</a>