kfogel@collab.net wrote:
> I'd like to get the language bindings out of the core Subversion tree
> and into their own project.
>
> Right now, the bindings face an impossible task: they're supposed to
> keep up with all API changes, and yet always be ready for release at
> the same time as the rest of Subversion. The results have been
> predictable: the bindings cause us release headaches every time,
> because there's never enough time to test them thoroughly. Anyone
> involved in releases lately can testify to pain. And it's not the
> fault of the bindings maintainers, who do a fine job under the
> circumstances. It's simply because we insist on treating the bindings
> as "part of Subversion", instead of like any other third-party project
> that needs to keep up with Subversion's APIs.
>
> My proposal is that they simply become an independent project. They
> would release their own tarballs, 'subversion-bindings-X.Y.Z.gz',
> where 'X.Y.Z' always matches the release of Subversion that those
> bindings are compatible for. They would have their own bug tracker;
> whether they have their own mailing lists or share svn's is up for
> grabs (I'm neutral on it). The most important thing, though, is that
> their release schedule would be totally up to them. A new bindings
> release for X.Y.Z would come out some time after the corresponding
> Subversion release. Whether that's one day, or a week, or a month,
> would depend totally on how quickly the bindings maintainers get them
> up-to-date and tested. Users who absolutely depend on bindings would
> simply not upgrade their Subversion until the relevant bindings
> release is ready. (Maybe the bindings tarball would unpack "into" the
> same subversion tree, creating a bindings/ subdir, or maybe it would
> work some other way -- that's an implementation detail.)
>
> I think life will be *much* easier for both core Subversion developers
> and bindings developers if we do this.
>
> Any objections?
+1 on moving them 'somewhere', but i'm curious exactly how this should
be handled. Several of the bindings depend on the same files (swig
stuff), but could easily be released separatly. Would we really want a
single subversion-bindings-1.0.x.tar.gz, or would it make more sense to
have subversion-perl-1.0.x.tar.gz, subversion-python-1.0.x.tag.gz,
subversion-java-1.0.x.tar.gz, etc. If that does make more sense, how do
we handle the files that are shared between various bindings?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 19:59:31 2004