strict response validation

[ota42y]

This changes break backward compatibility because when the user set strict option, old version is ignore but this version doesn't ignore.
So we should add warning on old version.

close: #317

[nicolasiensen]

Hey @ota42y, what is missing to merge this PR? I would be glad to help.

[ota42y]

Sorry, there's nothing problem with this PR.
We have not changed master towards 5.0.0 yet, so we can't merge this PR.

Since 5.0.0 is a major version upgrade, we would like to include several breaking changes.
And we are thinking of making a version 4.99.0 that outputs various warnings to users won't have trouble when updating.
In order to do this, we need to decide what changes we want to make in 5.0.0.

committee use openapi_parser gem for validating OpenAPI 3 and I would like to release a major version upgrade (1.0.0) as the same time.
https://github.com/ota42y/openapi_parser

So we should do these step

1. release openapi_parser 1.0.0
2. use it in commitee 5.0.0 and add breaking changes
3. release 4.99.0 for comfortable upgrade
4. release 5.0.0

In openapi_parser 1.0.0, drop old ruby version.
So we would like to add types and this is not done.
(This is because I add types by manually in many functions)
ota42y/openapi_parser#118

But it's taking too long..., and it's not a functional addition, I think I'll release to using more untyped 🤔

[nicolasiensen]

Regarding the openapi_parser, do you think it is a good idea to bump the Ruby version and add types in one go? Wouldn't it be more manageable if we bump Ruby first and add types in another version?

Besides bumping Ruby to 3, is there any other breaking change you plan to introduce to the openapi_parser 1.0?

Thanks for the detailed explanation :)

[ota42y]

My concern was that changing the defined form later would have to be treated as a breaking changes (and we need to update major version).
However, when I examined the version control in typescript, it was the management that the types can be changed frequently even in the same minor version.
As a result, I no longer have to worry about adding a type first and changing it later, so I'm going to release it with the current types.

[nicolasiensen]

That makes sense. Let me know if there is anything I could help with, ok?

[ota42y]

sorry, master branch's version changed 5.0.0, so I merge this PR

[ota42y]

I released 5.0.0 with this changes!
https://rubygems.org/gems/committee/versions/5.0.0