kfogel@collab.net wrote:
>
>>Questions about solution:
>>
>>o Do we need svn_error2_t for safe_message (for binary compatibility)?
>
>
> I would _think_ so. It's a public, open structure. Even if we add to
> the end of the structure, it won't be source-compatible with older SVN
> releases. It kind of depends how we interpret clause (2) in HACKING:
>
> 2) Upgrading to a new minor release in the same major line may
> cause new APIs to appear, but not remove any APIs. Any code
> written to the old minor number will work with any later minor
> number in that line. However, downgrading afterwards may not
> work, if new code has been written that takes advantage of the
> new APIs.
>
> Here, we're not causing a new API to appear so much as adding a field
> to an existing API. But now that I think about it, that's not so
> convincing. Maybe it is okay according to the guidelines. I'd like a
> second opinion.
Yes, it would require a new structure, which means reving each and every
function that returns an svn_error_t. Fun. The issue isn't that you're
adding an API, its that you're changing the ABI for that structure by
increasing its size, which is part of its ABI by virtue of the fact that
it's publicly declared in our header files. In some special cases we
document that the size is not part of the ABI (svn_client_ctx_t for
example), but I don't think we did that for svn_error_t.
That said, the common case is to create svn_error_t's via our
constructor functions, and I can't think of a good reason someone would
be depending on the size, but it is technically a violation of our
compat policy.
And yes, for what it's worth, I think in 2.0 we should just do away with
publicly declared structures entirely, it's just not worth the pain when
we finally do need to rev them. Even pulling the "the size can change!"
card isn't really good enough, since I've already seen at least one
example on the users list where someone went right past the note on
svn_client_ctx_t about using the constructor function and allocated it
on the stack themselves instead.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 23:05:05 2005