[net-dns-users] API regressions and coming shortened release cycle (was: Re: AXFR)

[Willem Toorop]

op 03-06-14 20:49, Chris Buxton schreef:
> When you find a subroutine not working as intended, try to fix it without breaking the observed/documented behavior in other ways. Sometimes this is non-trivial to do, but it's important. If it cannot be done, don't fix the existing subroutine — introduce a new method, deprecate the old method, and document the whole thing.

Absolutely.
This is also in line with the procedure I laid out earlier. I repeat:

op 28-05-14 13:49, Willem Toorop schreef:
> I think the best course of action for us would have been to:
> 
> 1. Introduce the new functions that will replace old ones.
>    The old functions should keep working the same as before
>    (without printing warnings)
> 2. Release with a notification about the new function, and the fact
>    that it will replace an old function.
> 3. Give users opportunity to switch to usage of the new function and
>    adapt their dependency on the new module version.
> 4. Adapt the old function to print the deprecated warning and
>    release again giving a warning about the function to be deprecated.
> 
> We'll make sure to use this procedure with similar cases in the future.

I will start a shortened release cycle for both Net::DNS and
Net::DNS::SEC to return former API functions and also fix some other
annoying regressions shortly.  There are some more reports on
regressions on RT I wish to walk through first.

Again my apologies; We'll make sure to better follow the procedure laid
out above in the future.

Thanks for giving all this feedback.  This is most helpful in
determining our cause of action, so please keep doing so.

Best regards,


-- Willem


PS.  Any objections to not return a socket with axfr_start anymore?  The
warning was in the documentation and the socket wasn't really suitable
for async processing, because