| <!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>Mid-December 2009</td> |
| <td>Roll 1.6.7 tarball</td> |
| <td><em>Pending demand</em></td> |
| </tr> |
| |
| <tr> |
| <td>January 2010</td> |
| <td>Branch 1.7.x</td> |
| <td><em>This date is highly speculative.</em></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.7 |
| <ul> |
| <li>Streamline HTTP transport to reduce the DeltaV overhead and |
| increase performance (see <a |
| href="http://subversion.tigris.org/issues/show_bug.cgi?id=3371">issue |
| #3371</a>)</li> |
| |
| <li>Rewrite the working-copy library to feature centralized metadata |
| storage and better future extensibility (see <a |
| href="http://subversion.tigris.org/issues/show_bug.cgi?id=3357">issue |
| #3357</a>)</li> |
| |
| <li>Augmented diff representation (svnpatch) (see <a |
| href="http://subversion.tigris.org/issues/show_bug.cgi?id=511">issue |
| #511</a>)</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> |
| </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 compatibility (autoversioning)</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> |