Justin Erenkrantz wrote:
> --On Wednesday, April 13, 2005 2:47 PM -0400 Garrett Rooney
> <rooneg@electricjellyfish.net> wrote:
>
>
>> I still think it's technically a violation of the policy, but considering
>> the difficulty of actually reving that structure and the fact that anyone
>
>
> My interpretation of HACKING and APR's versioning policy is different
> than yours then. ;-)
>
> So, to make this clearer, would there be any opposition to adding a
> clause like this to HACKING under compatibility guidelines:
>
> ---
> Structure Modifications
>
> Publicly exposed structures (i.e. svn_<type>_t) where a defined
> constructor is available (i.e. svn_<type>_create) may only be modified
> in the same MAJOR line by adding fields to the end of structure. No
> modifications to a public structure may be adopted in MAJOR.MINOR line.
>
> Private (opaque) structures may be modified at any time.
> ---
>
> Rewords welcome. =)
The only problem I have with this is that so far we've had some cases
where we've specifically documented "this struct can have fields added
at the end", and many more where we haven't said anything about it.
Going back and saying "oh, the presence of constructor functions implies
that it can change" just seems wrong. There may be specific cases
(svn_error_t, for example) where it makes sense, but the fact that we
have a function to automate some of the drudge work in filling in the
fields in a structure doesn't necessarily mean that relying on the size
is totally outside the realm of reason.
I'd prefer that we simply look at the publicly declared structures in
the tree now, document which fall into this category, and in the future
be careful about such things, mainly by making new structures non-public
when possible.
Unfortunately, since I'm in the process of packing up all my belongings
and moving across the country, I won't have time to do this in the next
few weeks.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 13 21:11:33 2005