Version 0.2.0 introduces breaking change due to version upgrade

[RobbeSneyders]

Hi @p1c2u

Version 0.2.0 introduces a breaking change due to the upgrade of the lower bound for the jsonschema dependency.
You can see this downstream in these packages:

• Incompatible with openapi-schema-validator 0.2.0 openapi-spec-validator#135
• Support jsonschema >= 4.0.0 spec-first/connexion#1430

Restricting the version range of a dependency should be done as a major version update. The iter_errors change (#25) and accompanying version range restriction also should not have been needed yet for jsonschema 4.0.0, as it only provides a deprecation warning for future versions. The current approach leads to a very narrow range of compatibility with jsonschema and other dependent packages.

My proposal would be to release a patch version 0.2.1 reverting #25 and fixing the upper version of jsonschema to 5.0.0. When jsonschema 5.0.0 is released and the old behavior of iter_errors removed, #25 can be applied again, and the version range updated to support both 4.X.X and 5.X.X versions.

[p1c2u]

Hi @RobbeSneyders

that was my intention to follow new interface of jsonschema 4.x-5.x with version 0.2.x and let 0.1.x support jsonschema 3.x.

I didn't change to version 1.x because the project is not mature enough for this, instead I changed the left-most non-zero digit to follow Caret versioning

[RobbeSneyders]

Fair point on increasing the minor version while still on 0.X.X, dependents should probably define boundaries on the minor version at this stage. It might be good to note though that caret versioning seems poetry specific, and not completely aligned with semantic versioning which is what most people will expect.

I still think my proposal is valid though. At this point the iter_errors change is unnecessary and limits the compatibility of open-schema-validator with both jsonschema and other packages depending on it.

[gberaudo]

Hi @p1c2u,

I didn't change to version 1.x because the project is not mature enough for this, instead I changed the left-most non-zero digit to follow Caret versioning

Do you consider versions 0.x to be ready for production? (and more generaly openapi-core ?

[p1c2u]

@gberaudo 1.x is planned to be stable for production, 0.x is marked as beta and you can expect issues.

@RobbeSneyders I think you're right we dropped support for jsonschema3 too early. I made dependency matrix for various versions

OAS	3.0	3.0	3.1
python	2.7+	3.7+	3.7+
jsonschema	2.x-3.x	3.x-4.x	4.x+
openapi-schema-validator	0.1.x	0.2.x	0.3.x
openapi-spec-validator	0.3.x	0.4.x	0.5.x
openapi-core	0.14.x	0.15.x	0.16.x

[RobbeSneyders]

Thanks @p1c2u, that matrix provides a great overview.

Does that mean you want to release a patch version 0.2.1 reverting #25, as proposed?

[p1c2u]

@RobbeSneyders
Yes I will do that.

[p1c2u]

Thank you for your help. Patch version 0.2.1 released hence closing.