Release blockers

[nicowilliams]

Let's set up a checklist of release blockers, possibly assigning milestones to issues.

[wader]

I started #2599 to draft a more detailed changelog with examples etc that also can be used as release notes.

[nicowilliams]

Also, are we doing a 1.7 or a 2.0? I think we'd need lots more features for 2.0, and maybe revisit some bad decisions. @itchyny @owenthereal

[pkoppstein]

Please let it be 1.6.1, to be released ASAP. That way, we can have our cake (an official release that's way overdue and that addresses numerous issues in 1.6) and eat it (all the goodies that are in the pipeline, whether in 1.6.2 or 1.7).

[nicowilliams]

Please let it be 1.6.1, to be released ASAP. That way, we can have our cake (an official release that's way overdue and that addresses numerous issues in 1.6) and eat it (all the goodies that are in the pipeline, whether in 1.6.2 or 1.7).

You get a say, of course. Hearing one for 1.6.1, I'm inclined to agree. Anyone else?

[wader]

Not enough new things in master compared to 1.6 for for 1.7 release? i vote 1.6.1 or 1.7 ASAP

[pkoppstein]

i vote 1.6.1 or 1.7 ASAP

Yes, I agree the emphasis should be on ASAP, whether it's "1.6.1" or "1.7".

Please also consider PR #2624 for this next release, as it addresses multiple issues with the existing gsub. It also significantly shortens builtin.jq even though it adds uniq/1, which is needed for gsub, so I made it global. If making it global is an issue, then of course it could be made into a subfunction.

Incidentally, the new gsub is significantly faster in the case of the example that was the subject of the (now-closed) Issue #1113.

[itchyny]

Let's release 1.7, since lots of new features including the numeric representation were added after 1.6. But before that, we need to revisit issues with bug label (again) and list all regressions introduced after 1.6.

[pkoppstein]

@itchyny wrote:

we need to revisit issues with bug label ...

That seems to conflict with the goal of the next official release
being published ASAP. If there is some expectation that most
significant extant bugs should be fixed before 1.7 is released, then
in the interests of "ASAP", I would once again draw your attention to
the virtues of having 1.6.1 ASAP and even 1.6.2 as its successor.

Forgive me for emphasizing again that some of the really terrible problems
in 1.6 were fixed long ago, and yet it's been nearly 5 years since 1.6
was released.

[nicowilliams]

The number of the release is not that important. My earlier question was more about whether people wanted to make this a 2.0 and if so why, and clearly that's not the case, and to me the difference between a 1.6.1 or a 1.7 is not very large. A major.minor.micro release versioning scheme tends to imply ongoing support for older releases, and even with an influx of maintainers we might not have the energy for that, so my preference would be for a 1.7.

[itchyny]

Honestly speaking, I don't think we need to release "ASAP", at least with a public tag like 1.6.1 or 1.7, since it's been years since the last release and I don't care delay for a few months. I think we can create a new release pipeline with testing tags like 1.7rc1, and fix critical bugs in the meanwhile.

[pkoppstein]

@itchyny - Over the years since jq 1.6 was released, there have been
many requests for a new release, often but not exclusively because of
constraints some users have with regard to unofficial releases.
Some of these requests have been made in "Issues" that have since
been closed e.g.

• In jq release #2155 titled "jq release" (in 2020):
  @weiganji asked for "a new version of jq in near future"
  @fusionneur asked for "an official new release"
  @vintnes pointed out "There are non-trivial issues with the last two releases."

• New version? #2525 titled "New version?" (@kloczek in Jan this year)

• A new version would be nice #2272 titled "A new version would be nice" (@hellow554 in 2021)

Other examples of requests for a new release:

• In organizing to release JQ 1.6.2 and JQ 1.7: Your suggestions/comments would be appreciated #2550, @liquidaty envisioned an early release (in the 1.6 series)

• Can we get a new release? #2327 is titled "Can we get a new release?" (@scottyob in 2021)

• In About the jq's release process (Was: Is jq is still alive/maintained ?) #2305, which dates from 2021:

• @chb0github wrote
  "Please consider growing the community and releasing soon"
  (About the jq's release process (Was: Is jq is still alive/maintained ?) #2305 (comment))

• @vintnes wrote:
  "I'm on record begging for a new release"
  About the jq's release process (Was: Is jq is still alive/maintained ?) #2305 (comment)

A closely related consideration is that some wonderful contributors have, over time,
been discouraged by the failure to incorporate their work into jq in a timely
way and by the general snail's pace of progress. Having an ASAP release would,
I believe, send a strong signal that development has resumed, and that
contributions have a reasonable chance of being incorporated into jq proper.

[itchyny]

Since I have created (reused) 1.7 release Milestone and we're working very hard towards the next release, so closing this issue now. Thanks to @owenthereal and @wader, the release pipeline is almost there, but we still need to build {darwin,linux}/arm64 binaries on GitHub Actions. I have contributed to Docker image building job to release to GitHub Container Registry, also fixed various bugs. I have also redesigned the website entirely with dark mode support and new SVG logo and icons (merge waiting for Firefox 116 release). We still have critical issues to fix until the release (can you believe echo foobar | jq . exits with 0 in the master version?). This is unofficial statement but I'm planning of releasing candidate in the mid of July and 1.7 on August 1. We promise to release soon, please wait for a while. Thank you.