New maintainer required

[erayd]

Unfortunately, I no longer have the time available to do this project justice, and have not for some time now. I've been dealing with things as I have the capacity to address them, but the PRs are coming in faster than I have time for, especially recently. I'm also the only active maintainer left, which is resulting in some pretty long delays in resolving things. This isn't good, given our significant downstream dependents.

I think we need to add another maintainer to take over the day-to-day stuff (PR reviews, merges, backports etc). If you are reading this and are keen to be involved in such a capacity, or would like to suggest a candidate, please comment on this issue.

---

@bighappyface - do you still have a comms channel with @justinrainbow? We will need him to deal with any new people added to the repo, as neither of us (nor @shmax, who has now moved on entirely) have the necessary admin permissions. If possible, it would be really good to get another person with admin permissions on the project (maybe me for now?) to reduce the bus factor here.

Also important that we be fairly careful about who we bring on board - we need to take into account the security implications if this project were to be compromised.

/cc @Seldaek - would appreciate your input on this; you're the most critical dependent we have.

[Seldaek]

Hey, I'd be happy to be added as an admin too here, because indeed Composer depends on it and it's the only dependency we have that is not under our control or part of symfony (which has a fairly decent maintenance outlook).

I however have close to no knowledge of the internals of this lib, and limited json-schema knowledge, so I am not likely to be able to do a lot of maintenance unless absolutely necessary and worth the time to dive in.

[erayd]

Thanks @Seldaek - I appreciate that. I think that adding you as an admin would be a good idea if you're OK with it. Even if you won't actually be maintaining it, you're a highly trusted party with an interest in the outcomes, and it would help to reduce the bus factor somewhat.

[erayd]

@robocoder How familiar are you with the internal workings of this library? I'm not seeing any previous contribution history from you.

[stof]

I don't think you can grant admin permissions to other people on a personal repository. So it might make sense to migrate the repository to an organization if @justinrainbow is not active anymore.

[back-2-95]

I was started a new Symfony project and need a JSON validation library. From the memory I came here as my colleagues have used this library for validating JSON schemas.

Now as there is this unfortunate situation, I'd like to just point alternative(s) to this thread so ppl like me can then decide which way to go. My (short) research found 2 alternatives:

• https://github.com/swaggest/php-json-schema
• https://github.com/opis/json-schema

You can check:

• which drafts library has implemented (aka what you need)
• which PHP versions are supported (your project's PHP)
• activity on default branch
• issues/pull requests

Example (me and my project):

• I have to decide asap
• I have quite simple needs so for drafts implemented they all are options
• I want PHP 7.4 || 8.0 support
• I wanna see activity on the repo so I can trust things working for a few years

All that said, it should be quite trivial to swap the library in the our app if needed. Maybe even create internal wrapper which you then use in your app and can just refactor the wrapper class when changing the library.

Lastly:

Thanks you @justinrainbow for all the hard work on the library and I wish all the best for you ❤️

[Seldaek]

@justinrainbow granted me access so at least that's one more person able to merge stuff now 👍🏻 What I wrote above still stands though, I am not very familiar with this library's code, but I do have an interest in keeping it alive as long as Composer depends on it.

[erayd]

Thanks for the update @Seldaek - that is really good to hear. Thanks @justinrainbow also for actioning that 🙂.

[back-2-95]

Thank you @Seldaek 🙏

[nickdnk]

Hello

Given the problem with the maintenance of this package, I would suggest you mark it as archived and point users to https://github.com/opis/json-schema. It's very close to a drop-in replacement for this and is actively supported, has no issues or open PRs, 2.2m+ downloads and supports PHP 7.4 and 8.0.

Thanks for making this though. Been using it for years.

[erayd]

@nickdnk Does that package support PHP 5.6, and draft-03 schemas? Neither of those things appear to be listed on the README page, and the requirements seem to indicate that PHP7.4 is required.

Unfortunately, backwards compatibility is a significant consideration for this library. Composer itself is a major dependant, so we can't just abandon old PHP versions lightly, even though they're no longer officially supported.

There are also still a large number of schemas out there which use draft-03 syntax for things. Not as big a deal as the PHP version constraint, but still a consideration.

[nickdnk]

@nickdnk Does that package support PHP 5.6, and draft-03 schemas?

The draft support is listed here: https://opis.io/json-schema/2.x/

It does not support PHP 5.6 which nobody should be using; and rightly so anything using PHP 5.6 should be considered legacy/archived code as well.

I'm not saying this is going to work as a drop-in for all projects on all platforms, but that for people running on modern platforms and not on unsupported versions of PHP, this is a good replacement. I did not say to remove this package from Packagist, just to suggest using something newer instead of having people set this package up in cases where opis could be used.