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

Re: Roadmap for 1.1 [placeholder]

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-03-31 23:52:34 CEST

--On Wednesday, March 31, 2004 1:38 PM -0600 kfogel@collab.net wrote:

> My apologies for the delay in posting a 1.1 proposal.

Here's my random thoughts for what I'd personally like to see in a 1.1:

I'd like to have the Java bindings straightened out for a 1.1 release. A
large portion of this work has already been done in trunk by myself and
dlr, but we need to get more eyes and testing with it (both the javahl and
SWIG/Java bindings). The current situation in trunk/ is far better than in
the 1.0.x branch, so the amount of work that remains is probably not that
much.

As far as i18n work, I think having a first cut at client-side translations
is going to be feasible in a 1.1 timeframe. I think the server-side error
messages are going to require serious discussion, so they may not be
feasible for a 1.1-timeframe. The supporting build framework is now mostly
in place (modulo some further tweaks to catch edge cases), but we're going
to have to _() escape all of our messages, and push for translations from
the community. Perhaps we need to run a straw poll to see who can help
with i18n translations? I'd see recruiting translators as the largest
obstacle here.

As I've mentioned before, I'd like to see us clarify and simplify our
release practices and procedures. This has fallen off my radar due to the
gettext stuff this week, but I should hopefully find some time soon to
start a thread to rethink how we should conduct a release. Yet, in order
to come up with a concrete proposal, I need to do some more investigation
into what we are doing now and why. But, any new release techniques should
coincide with a 1.1 - the 1.0.x release procedures should be 'frozen.'

I think we can also get the locking-plan.txt implemented for a 1.1. This
is probably the 'largest' cross-cutting feature that I think we should add
into a 1.1. Greg's proposed libsvn_fs_fs shouldn't affect everything, but
locking would require changes through almost every part of the code in some
fashion. Perhaps now would be a good time to review locking-plan.txt and
see if it all still makes sense? (I haven't looked at it in detail since
we wrote it over 18 months ago!)

For my pie-in-the-sky feature, I'd like to see full DeltaV-compliance for a
1.1. I don't know my time commitments yet, but this omission has been an
annoyance to me so far - it certainly isn't critical though. I've heard
we've got a Java-based DeltaV client floating around the office here. So,
I might pick that up and see what happens (I know it doesn't work quite
right against SVN); but certainly no promises for how involved I'd be.

Wow, I had more to say than I thought I did. ;-) -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 23:53:09 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.