On Fri, 20 Feb 2004, Ben Reser wrote:
> On Fri, Feb 20, 2004 at 11:44:38AM -0600, 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?
>
> In favor of the idea. But there's lots to figure out as far as
> implementation.
Is all this going to happen before Subversion 1.0.0 release or later? If
before then that's pretty close timing for those changes to the Subversion
tree (unless they are completely mundane). However, if it is going to be
done I'd say do it before releasing Subversion 1.0.0 as long as users can
get the packages they've been using up to know along with the Subversion
1.0.0 packages.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 20:51:54 2004