[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Proposal: begin 1.1 release stabilization.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-06-07 18:41:36 CEST

The Chicago guys have been chatting, and we think that it would be good
to start stabilizing for a 1.1 release. I hope others agree.

* Why release 1.1?

  As Mark Phippard pointed out, there doesn't seem to be any good
  reason to delay svn 1.1 for a locking feature. The locking stuff is
  still in the design phase, and meanwhile /trunk is full of all sorts
  of great new things. It's been nearly four months since 1.0 was
  released, so the time "feels right" for 1.1. Users shouldn't have
  to wait for locking to be designed and written to start using the
  new features.

* Major highlights of svn 1.1

   - new plain filesystem repository back-end (libsvn_fs_fs)
   - framework for localized errors, with a few initial translations.
   - diff and other commands correctly follow renames (issue #1093)
   - libsvn_wc scalability & speed improvements
   - new 'svnadmin dump --deltas'
   - new 'svn export --native-eol'
   - (?? improved bindings ?? bindings and win32 build improvements??)
   - many bugfixes that couldn't be backported to 1.0.x

     ...any other major things I've forgotten?

* Proposed Action Plan

  1. Cleanup of loose ends.
      (Can't yet estimate how long this will take.)

       - Look at issuetracker, decide which open issues (if any)
         should considered 1.1 "showstoppers". Fix them ASAP. Fan
         out remaining issues from 1.1 to other 1.X releases.

       - Allow any other code-cleanups in process to come to a
         good stopping point.
  2. Copy /trunk to /branches/1.1.x and release a 1.1-beta1 tarball.
      (This procedure is described in the HACKING file, take a look.)

  3. Allow the 1.1 branch and 1.1-beta1 tarball to "soak" for four
      weeks. If necessary, release subsequent beta tarballs duing
      this time. (Again, this is all described in HACKING.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 18:42:30 2004

This is an archived mail posted to the Subversion Dev mailing list.