On Wed, 2004-03-31 at 21:41, kfogel@collab.net wrote:
> * l10n (also known as i18n or "that gettext thang")
> * Locking (reserved checkouts)
> * Issue 1093 and friends (diff-follows-copy-history, etc)
> * Straighten out Java bindings
> * Improved release procedures & scripts
> * Full DeltaV compliance (called "pie in the sky" :-) )
> * In-repos ACLs (may be intertwined with reserved checkouts work)
> * True rename support, at least in the repository
> * symlink support
> * "What about plug-in client-side diffs?"
> * Fix N specific bugs (many in issue tracker are already marked as
> "1.1", though that set is not written in stone of course)
If you throw in merge-tracking and distributed operation, you've got
just about all of our wishlist there. That's not much of a roadmap, in
that it doesn't help us decide when we're ready to make a 1.1 release.
(Nor does it tell developers what to focus their efforts on, but I doubt
many developers are interested in such guidance anyway; we all have our
pet interests.)
I think the right way of thinking about this problem is:
* What features would make a 1.1 release interesting?
* Are any features absolutely essential for 1.1?
* When do we want to target a 1.1 release for?
Something like three months before the 1.1 target date, we need to look
at what's ready to go and cut bait on the rest, since we'll want to
branch and go into beta testing around two months before the target
date. If we don't have at least one of the "interesting enough"
features by then, or if we don't have any of the essential features (but
are making progress on them), then we delay. If 12-18 months go by and
we *still* haven't finished anything interesting, then we should decide
that we've stalled and release a 1.1 with minor improvements, but that
seems pretty unlikely.
I'm not going to call any feature absolutely essential for 1.1, myself.
Of the features listed above, I'd say the ones that would each make a
1.1 release worthwhile by themselves are:
* Locking
* Java bindings
* In-FS ACLs
* True rename support
But true rename support may be too hard to implement in a fashion that's
acceptable for 1.x, and it's probably too hard for this time frame
anyway. Likewise, libsvn_fs_fs, libsvn_fs_sql, history-sensitive
merging, or distributed operation features would be interesting enough
for 1.1, but I don't anticipate any of them happening in that timeframe.
As for features which are neither "interesting enough" nor "essential,"
the 1.1 roadmap isn't supposed to discourage anybody from working on
them, although other factors might. For example, symlink support would
complicate a libsvn_wc which cannot really tolerate more complication,
so first we'd have to kick off a redesign effort, and maybe we'd rather
not do that while we're trying to implement locking and FS ACLs and
localization and libsvn_fs abstraction and a few of us are working on a
new FS layer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 1 06:38:42 2004