Re: stabilization & number of changes

On Wed, Jan 07, 2004 at 02:46:26PM -0500, Greg Hudson wrote:
> On Wed, 2004-01-07 at 07:07, Greg Stein wrote:
> > While I believe having a great API is nice, I don't see it as affecting
> > the users of the software. And it is the users who are our primary
> > audience.
>
> Indirectly, it does affect the users of the software, in proportion to
> how many of them use svn through outside applications. If we consider
> the API to be a secondary feature of the release, we may as well not
> have it. (perl provides an excellent example of a package which has a C
> API and may as well not, because it considers the C API a highly
> secondary feature of the package and consequently provides miserable
> compatibility guarantees.)
>
> So, strong disagreement on this point.

I totally agreen with Greg Hudson on this point. The API will be my
primary method of using subversion soon. In my particular
implementation I need a superset of the features offered by the command
line client. The API provides me the tools to do that. I wouldn't have
spent as much time as I have getting the perl client bindings up to
speed if it wasn't so important.

> Elsewhere, Greg Stein wrote:
> > One of my underlying reasons for avoiding API changes right now is
> > that you can view the set of available software as a sort of
> > "ecosphere" of tools around SVN.
>
> I want to address this because, on the face of it, it appears to put us
> on the opposite side of the API-importance table from where we were
> earlier in this message.
>
> We've never claimed that 0.x releases have a fixed API, and in fact
> we've made a large number of API changes between 0.x releases in the
> past. We've known that early adopter projects like TortoiseSVN and
> RapidSVN suffer as a result of API changes, but they're early adopters,
> so that's acceptable. We should not use them as an excuse to avoid API
> changes now, while we're still in the 0.x cycle, at the expense of
> making the SVN 1.1 API more baroque than it has to be.

I'd say Greg Stein's comment here is an argument for making the changes
now. If we want to view things as a group then we might as well get the
pain overwith. While we're doing our soak time, why not spend some time
going to the various projects using subversion and trying to cordinate
updated versions of their program to match our APIs?

Looking at the votes we're going to have API changes betwene 0.35.0 and
1.0. So let's get the API stuff out of the way now.

I'd be more than happy to spend some time working on helping get some of
the other projects API issues dealt with. RapidSVN for example doesn't
seem to keep up with subversion at all. ISTR it went from a 0.29
compatable version to a 0.34 compatable version and within days 0.35 was
released and broke it again.

So we've already got projects that won't work with the existing releaesd
versions out there. It's going to take some special effort to see to it
that they get updated.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org