Hey Stefan, > For example, the addition of new functions prevents people from rolling > back to an earlier 1.7 patch release without breaking scripts which were > modified to use the new functions after updating to 1.7.3. That would > be a violation of our release compatibility guidelines. Hmm, that's a pity, since the addition of this new unlock_prompt_func function would really be the one commit I'd like to see backported (I only did the other patches for consistency and because I now better understand swig than a year ago when I did the perl patch).
Also, if I understand your policy correctly, backporting the below patches isn't exactly useful either, since any script that will be modified to use the svn_auth_get_platform_specific_client_providers will break as well when downgrading to 1.7.2 (since there this function (binding) exists, but will always error out). I guess the distinction between "add a new function" and "fix an unusable function" is a bit vague here. Or does the policy concern the C API? Since all of the patches (including the unlock_prompt_func one) only touch the bindings, not the actual C api. Gr. Matthijs > Changes which don't add new API symbols can be backported. > Currently, the following changes are nominated for backport to 1.7: > > * r1241530, r1241713, r1241726 > Fix the python bindings for > svn_auth_get_platform_specific_client_providers. > Justification: > The bindings should see passwords cached in the platform-specific > providers. > Already fixed for the Perl bindings. Ruby fix is nominated separately. > Notes: > r1241713 and r1241726 tweak the unit test. > Votes: > +1: danielsh > > * r1241553 > Fix the ruby bindings for svn_auth_get_platform_specific_client_providers. > Justification: > The bindings should see passwords cached in the platform-specific > providers. > Already fixed for the Perl bindings. Python fix is nominated separately. > Votes: > +1: stsp > >
signature.asc
Description: Digital signature
