We, the maintainers, ran out of energy. We had big PRs to work on that sucked a lot of energy, then covid happened, and lots of distractions, and now we have no active maintainers. The community at times got unruly and required bursts of our energy. Will and I felt burned out on jq.

That said, I'm trying to bring on a new maintainer, and I'll try to find energy during the holidays, which is when I usually find energy for jq. Also, I can't reach Stephen, which means the only way to add new maintainers is to fork the project, which I don't want to do without Stephen's approval. I've created a `jqlang` org in GitHub just to squat on the name, but before I ever fork it, I want Stephen's approval, and I want him to accept ownership in the org -- it's his baby!

You guys did a great job with jq so thank you for everything you've put into it. It's a tool I use multiple times a day, every day. Also, I love your documentation page!

When I saw the comment "why is the latest release so old" my thought was "because it's perfect".

It needs a bunch of love. It really needs a way to define new builtins externally, and it needs co-routines. And it needs a way to do binary (my idea: treat binary as an array of small integers, and if you ever insert any other kind of value, then you either get an error or you get an array that's mostly of small integers and no longer "binary" in any way).

Damn, sorry to hear that the cycles became so draining.

It's such a powerful tool at surface level in this api/k8s interfacing world that looking under the hood and seeing all the work just knocked me over.

You all have done something so powerful for the community regardless of the hiatus.

THANK YOU!

If you can't reach Stephen directly maybe you can try to reach him via Yaron Minsky.

Thanks for the clue. I'll try that.

Thank you for producing such an excellent language! I'll always recommend it, its come in handy so many times and fits nicely in a lot of workflows.

Thank Stephen Dolan.

Thank you so much for JQ. It has been my secret weapon in more than one instance.

I've always been curious, what do maintainers that are trying to pass the torch look for? Surely there are a huge amount of people that offer but they mostly get rejected. What makes a good candidate?

Contribution quality. When Stephen made me a maintainer, he did it because I kept sending him PRs he liked, and he was losing energy for jq. When I asked Stephen to make Will and David maintainers, it was because their contributions were of very good quality. Problem is I've fallen way behind on keeping up with issues and PRs, so right now I don't know who would be a good candidate. The other problem is, as I mentioned elsewhere, that I cannot make someone a maintainer -- only Stephen can. If Stephen agrees to a `jqlang` org, then it will be possible for him to delegate authority to add new maintainers.

If there's no planned changes or unreleased work in the repo, then there's not much need for more releases. Jq is a pretty small tool and isn't obviously incomplete.

Though it's funny because I do agree that in the past that jq wasn't having its committed code being released often enough. There was a popular Github issue[1] with arguments and 70+ reactions about a confusing feature in jq that turned out to have already been fixed and committed in 2015, before the Github issue was even opened, but the fix didn't actually make it into a released version until 2018. Definitely one of the more frustrating cases of investigating a software issue I ran into. Everyone should make sure their project's release process can promptly release updates!

[1] https://github.com/stedolan/jq/issues/1110

It isn't obviously complete either, and definitely still has bugs. And there are significant changes on master that haven't made it into a release yet. I think it is more that the maintainer(s) no longer have a lot of time to put into it. Which is fine and understandable. Maybe eventually a fork will gain enough traction to take over, or maybe one of the alternatives will become more popular, or maybe the maintainer will come back, or pass it on to someone else.

I've also wondered this, afaics the project appears effectively unmaintained, ci appears to have been broken for a while, and both pull requests and issues piling up with not much response. it does appear there are several other folks with commit access to the repo :shrug:

It works, and does what it is supposed to. Why does it need a new version?

To compete with the newer, blazingly fast tools

What are the competitors in the jq space?

At least jaq[1] gojq[2], and jp[3] (this last of which is jmespath rather than the jq query language)

[1]: https://github.com/01mf02/jaq

[2]: https://github.com/itchyny/gojq

[3]: https://github.com/jmespath/jp

I especially love gojq thanks to this change:

    $ echo '{"alpha":"beta"}' | jq -r '"hello \(.alpha\)"'
    jq: error: syntax error, unexpected INVALID_CHARACTER (Unix shell quoting issues?) at <top-level>, line 1:
    "hello \(.alpha\)"
    jq: 1 compile error

    $ echo '{"alpha":"beta"}' | gojq -r '"hello \(.alpha\)"'
    gojq: invalid query: "hello \(.alpha\)"
        "hello \(.alpha\)"
                       ^  unexpected token "\\"

because (a) muscle memory (b) sure, it's easy to spot that mistake in an 18 character expression, but for bigger ones, getouttahere

There's a particularly complicated system I built a few years ago that heavily leaned on jq for configuring some backend systems. It had lots of variables piped in and so that particular error was common. From your snippet, I'm pretty sure gojq would have saved me many hours of debugging.

Yeah the ergonomy and error messaging of jq is complicated

I'm not a big fan of the language, but it works

jp --help

"It's complicated, you know"

Xidel for XPath on JSON, XML, and HTML: https://github.com/benibela/xidel