[Koha-bugs] [Bug 30275] Checkout renewals should be stored in their own table

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30275

--- Comment #224 from Ere Maijala <ere.maijala at helsinki.fi> ---
(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.