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.

[back-2-95]

If using PHP 5.6 which is EOL and unsupported then I guess it's OK to use old releases of justinrainbow/json-schema.

My understanding is that even if repo is archived, the old releases are available through Packagist.

[nickdnk]

If using PHP 5.6 which is EOL and unsupported then I guess it's OK to use old releases of justinrainbow/json-schema.

My understanding is that even if repo is archived, the old releases are available through Packagist.

Exactly.

[nickdnk]

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

I did not see you had already mentioned this, @back-2-95.

[guilliamxavier]

Even if you don't care about draft-03, remember that Swagger and OpenAPI < 3.1 use [an "extended subset" of] draft-04

[Seldaek]

For Composer we'd probably switch to swaggest/php-json-schema if we switch at all, as it supports PHP 5.4+, and we need at least 7.2+ going forward. 7.4 for opis/json-schema is not workable for us. That said I don't think we have a need for the latest json schema drafts as draft 4 seems to do the job at the moment and I don't expect big changes in our schema.

[Seldaek]

I'd like to get this repo up to speed with GH actions, perhaps phpstan, and get things built on PHP 8.1 etc.. But I am quite confused by the branching strategy.

It looks like branch 5.x.x is both behind and ahead of master. Branch 6.0.0-dev is pretty much the same as master. Releases appear to have been done from 5.x.x until now, and it has a bunch of backport commits.

• Is the strategy to commit fixes to master, and then pull them as backports into 5.x.x for release?
• Is master meant to be "v6"?
• Does this make sense if nobody is going to work on master/v6 it seems?

If anyone can shine some light on the situation that would be most helpful. I don't want to make even more of a mess :)

[Seldaek]

Some more git digging makes me believe master is indeed v6 dev, the 6.0.0-dev branch should probably be merged then deleted.

Now my question would be.. what is missing for a 6.0.0 release? Is master not stable? Were there features missing? Could we release it as is and then abandon the 5.x.x branch so we have to stop doing backports (trying to reduce maintenance work here as nobody has time for anything..)?

[erayd]

Is the strategy to commit fixes to master, and then pull them as backports into 5.x.x for release?

Yes. Not all PRs are backwards-compatible with 5.x.x, but those that are, I have been backporting.

Is master meant to be "v6"?

Yes.

Does this make sense if nobody is going to work on master/v6 it seems?

Many people do work on master (v6). It just doesn't have a published release version, because it isn't finished (there are a few outstanding bugs, and a lack of documentation) - however, functionality-wise it works for most purposes.

Some more git digging makes me believe master is indeed v6 dev, the 6.0.0-dev branch should probably be merged then deleted.

It's already been merged, and master has since diverged from it. The 6.0.0-dev branch should be deleted without further merging it; there is nothing in that branch which is not already incorporated into master a long time ago.

Previously, 5.x.x was master, and the work was happening in 6.0.0-dev - however, people kept opening PRs against master despite the instructions saying to open against 6.0.0-dev. We moved to the current branch naming in order to resolve this, so that master was actually the correct PR target.

What is missing for a 6.0.0 release?

A few outstanding bugfixes, and documentation.

Is master not stable?

Master (v6) is stable, however there a few specifric situations where it is known to violate the spec. These are the bugs I refer to above.

Could we release it as is and then abandon the 5.x.x branch so we have to stop doing backports (trying to reduce maintenance work here as nobody has time for anything..)?

If you are happy to push out a slightly buggy 6.0.0 release, yes.

For what it's worth, the backports aren't usually too much hassle to merge. I usually just run a git cherry-pick on the relevant PR merges from master to apply them to 5.x.x. Occasionally something also needs to be refactored to make it work with 5.x.x. This typically takes under half an hour every few months; the conflicts don't take too long to resolve (although this is partly due to the lack of major progress; I expect these would become more of a hassle if there was a larger amount of work occurring on the project).

If you take a look at previous backport PRs, in the description for each I list the PRs merged to master since the previous set of backports, and categorise which were backported, which were skipped (and why), and which weren't applicable to the 5.x.x branch.

[Seldaek]

@erayd ok many thanks for putting it all down here in detailed form. It kinda matches what I ended up understanding but it's good to have it documented somewhere.

[Seldaek]

Also: I have now deleted the 6.0.0-dev branch to reduce further confusion.

[DannyvdSluijs]

I've always been fond of the package and recognize the work here that has been done by @justinrainbow and contributors.
Seeing some of the comments in the issues, the number of open pull requests and missing out on keeping up I was wondering if contributors are still welcomed?

I would like to offer helping out and see if we can revive the package and help the community. As a maintainer and contributor I know help from others is valuable and needed, But I can't do it by myself not do I want to do this alone. In order to help out I could do:

• Triage any open issues
• Change open PR for completeness
• Create Pull Request which help with
  • Update pipeline to latest version to resolve nodejs version warnings during run
  • Add overview in repo which drafts are supported/not yet supported
  • Issue templates to collect all the desired info when people take the effort to report an issue.
  • Setup security policy
  • Build a wiki with more detailed scenarios covering the different drafts which are supported by the library

But that also requires someone/others with permissions in the project to

• Close issue when unable to reproduce
• Merge PR when reviewed, pipeline is green
• Review PR in order to improve pipeline and project side of things

Is there anyone who still feels like putting in the effort? @erayd @Seldaek @bighappyface pinging you guys a based on the release and comments in the issues it seems you're at least having some permissions to do so. Sorry to be this direct and a clear "No" is also fine for me, but I would like to make sure putting in the effort is at least having a change.

[erayd]

@DannyvdSluijs Help would very much be appreciated - thank you!

I'm chronically short of time, so the biggest bottleneck is likely to be code review. Small changes are easier / faster to digest than big ones, and more likely to get merged. If you know a second person who is highly familiar with the library and has the capacity to take on some of the review load, that would help a lot too.

For clarity, while I'm usually able to respond promptly, I don't have the time to do much. If you do choose to contribute here, the reality is you'll be carrying most of the load alone, and anything that requires significant amounts of my time (especially complex code review) is likely to be very delayed.

Probably the most helpful thing you could do right now that wouldn't be too bottlenecked is issue / PR triage. If you create a master issue with a list of what needs closing, and what needs to remain open (and possibly tagged), I'm happy to go through the list & action them accordingly. That will then at least clear out the stuff that's no longer applicable, and make it clearer what is left that actually needs attention.

[DannyvdSluijs]

Thanks for the quick response. That at least shows there is a sign of life for the project and that it at least is worth putting effort into it. I'll try and see if I can first focus on issue cleanup (triage and follow-up on reporters).

I'll also see if I can review some of the pending PR's before creating new ones (maybe a couple to help with issues, such as #709) to not overload review process and create rebasing work for contributors.

Besides all the missing draft support and issues it also seems this project could benefit from a pipeline revamp. Has there been any discussions about supporting older PHP versions? Based from the packagist.org stats if we would drop PHP <= 7.3 we would only leave 7.4% of the install stuck at the current version and can shake quite some technical debt and help out people on newer versions with some speed improvements due to raising the minimum level and calling more efficient functions.

[erayd]

Thanks @DannyvdSluijs - that sounds wonderful 🎉

On the version thing, please see #706 (comment). Note that Composer is a dependent of this project (see #706 (comment) for their current requirements), so we need to be more careful about backwards-compatibility than most other libraries, and we'll always likely need to keep supporting some EOL versions of PHP as a result.

[dafeder]

Wanted to note that as of April 2024 the picture looks very different: Opis has gone over two years without a new release and has some pretty low-hanging fruit (like opis/json-schema#130) just sitting there in the PRs with no response from the maintainer. I've been using both these libraries for a long time but am leaning toward finally consolidating on this one unless we see some signs of life at Opis.

Much appreciation to the people keeping this package moving! (Opis is a great piece of software too, hope to see that resurrected as well.)

[DannyvdSluijs]

Intro

I believe since end of March we've made good progress with the cleanup of old issues and pull requests. I've been trying to see what would be the next steps forward. Which has led me to posting this comment.

Next steps

After seeing some of the comments on issues and pull requests I've been working on some milestone ideas (A milestone doesn't have the a mayor release)

1. Get version 6.0.0 shipped: This will resolve issue for people that have been reporting them based on older branches. We can limit the support to the last two mayor versions..
2. Bump to minimum PHP 7.2 / Compatibility with PHP 8.4: This has been widely discussed and @Seldaek has confirmed PHP 7.2 is the lowest we should still support.
3. Improve automation: With time being like gold in OSS, using workflow files for CI/CD, Issue management, Issue forms harnessing the power of GitHub can be a great time saver.
4. Keep fixing bugs, triage tickets: With the release of 6.0.0 we might get some new issue reports and we still have some open issues and pull request which we should work towards getting down to zero.
5. Improve documentation: Documentation is always an afterthought but very important with library packages. We should out effort in the docs , examples and functionalities.
6. Include support for newer schema versions: As it says on the can we should support the newer versions of the JSON schemas
7. Promote justinrainbow/json-schema When we are all said and done we should promote this library once again on json-schema.org to be back (https://json-schema.org/obsolete-implementations#validators-php / Source)

I can't do this alone

I'm still really happy to help out and I get the feeling other people as well, there is s positive vibe going on. There is just one key element which is required to make progress, which is a person(s) who can merge pull requests, create new release etc. In my eyes this requires either time from the original authors or a new maintainer is actually appointed which such permissions. And even with just me as an additional maintainer I would still like for someone to pair-review any of my pul requests.

I don't have a preference for either option but I feel like we need to pick one and go for it. Otherwise the project will be back to it's limbo state from a couple of months ago. This project has some great potential to grow and just making a fork and steal the thunder from all previous work done here by others just doesn't feel right.

Question

So @erayd if you could spare maybe ten minutes to tell us how you would see this project move forward that would be a great insight for me and many others as well. Also I don't want to put you on the spot there is no obligation whatsoever, I'm just trying to chase down this issue and push it over the finish line. Thanks for all you work on justinrainbow/json-schema so far.