Skip to content

Backwards compatibiliy for 1.x release#11

Open
eval wants to merge 1 commit intobody-nilsfrom
towards-two-dot-o
Open

Backwards compatibiliy for 1.x release#11
eval wants to merge 1 commit intobody-nilsfrom
towards-two-dot-o

Conversation

@eval
Copy link
Copy Markdown
Collaborator

@eval eval commented Jan 15, 2026

Before this commit when handling OmniKassa2::OmnikassaError it might have handled Omnikassa2::HttpError's.
This might have been the (unlikely) case where there's an unsuccessful response containing valid JSON.
With HttpError no longer inheriting from OmnikassaError this would break. Now ApiError takes it place until 2.0.

A deprecation warning is shown (also to those handling JSON::ParserError) to migrate to HttpError or OmnikassaError before 2.0.

Code Review

Please consider the following checklist when reviewing this Pull Request.
More background and details here.

  • Does the code actually solve the problem it was meant to solve?
  • Is the code covered by unit tests? Integration tests?
  • Does anything here need documentation? (Focus on why, not what.)
  • Does any of this code deal with privacy sensitive information or affects security? Ask an additional reviewer.
  • Is the code easy to understand and change in the future?
  • Is the same code or concept duplicated? Find a balance between DRYness and readability.
  • Does the code reasonably adhere to the Kabisa coding standards?
  • Be kind.

Before this commit when handling OmniKassa2::OmnikassaError
it might have handled Omnikassa2::HttpError's.
This might have been the (unlikely) case where there's an unsuccessful response
containing valid JSON.
With HttpError no longer inheriting from OmnikassaError this would break.
Now ApiError takes it place until 2.0.

A deprecation warning is shown (also to those handling JSON::ParserError) to migrate to
HttpError or OmnikassaError before 2.0.
Copy link
Copy Markdown
Member

@rbr rbr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be easier to just release the changes on master as a 2.0 release?
What's the added benefit of making a 1.1 for which there might be some risk of breaking something somewhere?

(I appreciate the effort put in to cover the situation we see, but with all the changes I'd think it's easier to not bother with a 1.x release.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants