On Fri, Dec 19, 2003 at 12:15:26AM -0800, Justin Erenkrantz wrote:
> Perhaps a bindings/experimental directory would make it more clear that
> this is a work in progress? I don't know what the right thing is.
That's problematic because you'd have to spend a lot of time breaking
the SWIG stuff up. Especially since you consider the python bindings
stable.
> I'm just indicating what should be in place for 1.0 not 0.35.0. Things can
> definitely be merged back into 1.0 from the trunk after 0.35.0 goes out.
> (My perspective, though, it should be like everything else: it needs 3 +1s,
> etc.)
Not arguing that point. I think at least with the perl bindings there's
a compelling case of merging a lot of stuff. Even if that means some
backporting from what I've got done (e.g. if the authentication API
changes don't make 1.0 then I'll have to change some stuff in the stuff
I'm going to put up shortly.)
I just don't want to be held to supporting what is in there for 0.35.0
as a stable interface in the future. The work I'm doing now would be
significantly more complex to stay compatable with the way things are
now. And frankly it wouldn't be very valueable because I can't imagine
anyone wanting to use the perl bindings for the client side stuff the
way they are now. I'm not sure where clkao is with the other stuff,
I'll let him speak for himself on that.
> There are enough projects using the python bindings that I'd consider those
> definitely stable. If my mailer.py dies on a hypothetical 1.0.5->1.0.6,
> I'm gonna have a heart attack. I shouldn't have to worry about the python
> bindings breaking after we go to 1.0 as I consider it 'core.' (I consider
> everything under /trunk core, but that's besides the point.)
That may be. I don't know much about the python bindings because I
haven't used them. Looking at the .i files, I'd guess there are some
holes in the client API that aren't implemented (prompt callbacks). But
I may be wrong and that stuff may work right already.
> So, we could work from the other direction as well: what bindings are
> considered stable and can't break 'older' 1.0 clients in a 'minor' release?
Unless someone says otherwise the only ones I've heard anyone suggest
would qualify for that would be the python and javahl ones. I may get
to a point in the next week where I could say otherwise for the client
side stuff on perl. But I haven't even started looking at the wc lib
wrappings.
> I'd say anything related to generic SWIG (i.e. the .i files) and the
> Python-specific stuff fits needs to have the compatibility rules enforced.
There isn't a whole lot of "generic" SWIG stuff. Pretty much anything
in the .i files is language specific. The likelyhood that anyone would
need to change the stuff that isn't seems pretty slim to me. But I know
there's stuff in the .i files that isn't complete for perl at least.
Plenty of FIXME's.
So in summary. I'm fine with 3 +1s for binding updates. I do think we
should be a little more flexible on what we merge in for the ones that
are incomplete. But by more flexible I don't think automatic approval
is the answer either. I just think they shouldn't necessarily be held
to the standards that we would hold the C API too regarding not making
major changes. I don't see any way to get them up to snuff without
making some major changes.
--
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
Received on Fri Dec 19 09:55:12 2003