Karl Fogel wrote:
> Specifically, I think we are lacking appropriate expectation management
> on merge tracking. It's not enough to document what it does; we must
> also document what it *doesn't* do (yet) that people might be expecting
> it to do.
>
> The most important place to do this is the release notes. The book
> should also do it a bit, but that has to be carefully worded because
> some of those missing features will be implemented during the time the
> book is still in print.
Nah, the book claims to document a particular pegged release of Subversion.
If the printed work goes stale once 1.6 is released ... well, that's just
the way those things go. We still have the online version which can be kept
as up-to-date as possible.
The dev community has not felt compelled to help the book authors ensure
that our text was up-to-date and relevant for any of Subversion's recent
prior releases. Our 1.2 version was tagged 12 months after the release of
Subversion 1.2.0. Our 1.4 version trailed Subversion 1.4.0 by 11 months.
And we never even did a 1.3 version.
Don't get me wrong -- I'd *love* the help in ensuring that Subversion 1.5.0
is properly documented in the book text, *especially* since Ben, Fitz and I
are dancing with O'Reilly right now, trying to release a printed document as
close to the 1.5.0 release date as possible. But that added requirement
would be new to this release, and is not (in my opinion) something that
we-the-Subversion-devs should necessarily assume as a blocker of this release.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-03-12 19:17:46 CET