https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30275
--- Comment #224 from Ere Maijala <[email protected]> --- (In reply to Tomás Cohen Arazi from comment #223) > (In reply to Ere Maijala from comment #221) > > API to keep it backward compatible? Could the renewals field be added back > > as an alias for renewals_count? > > I agree this is annoying. The main reason for the change in the name was to > reuse the 'renewals' attribute for x-koha-embed(ding) the renewals. > > Not sure what to do. If this is critical for the vuFind integration > maintainers we could reconsider. Fortunately this one is not critical, and since the change had already shipped in a released Koha version, going back could cause even worse confusion. VuFind has been adjusted (see https://github.com/vufind-org/vufind/commit/7d8b08fb43027dfaec2ef8417ba34c8aadcfe2e1), though a new release is needed for everyone to get the fix. Since renewals will be re-used (and I think for a good function), my suggestion for an alias is not a good one either. At this point I suppose what's left is a wish to avoid such changes in the future, but if they're needed, at least publish a prominent note about the BC break in release notes. v1 API being incomplete is not a problem as long as new functionality doesn't break compatibility. And even if the v1 API was considered "alpha" level and subject to change, it's really difficult for an API consumer to manage as they might not even be aware of a Koha upgrade being done. I understand it's difficult to always stay compatible, and others have failed as well even when they've introduced changes with new API versions. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
