Request for more frequent releases

[wknapik]

Hi. Can you please release more frequently ? It's especially relevant in CI.

[koalaman]

What's the goal here? More up-to-date checks without the instability of git builds?

[matthewpersico]

There’s that. There’s also the fact that I can’t put git builds into production at my job; I need versioned releases. We build from the source but it’s got to be “official”, so I just need the tag of an 0.8.0. Others will need the bits. -- Matthew O. Persico

[dimo414]

Seems like a policy problem if you can't use the code you need just because it lacks a GitHub tag. You should be evaluating software for production safety based on its content, not whether the maintainer has made it "official".

Nevertheless, it looks like the last release was in Jul 2019, it would be nice to push out all the changes that have landed since then. So +1 to the FR just since releases are often easier to work with. Especially for folks getting ShellCheck via a package manager like apt-get.

[matthewpersico]

No it’s not a policy problem. Each and every piece of code that is brought in from the outside must be vetted to ensure we are not violating the license terms. I’ve been in more than a few places in my 32 year career in software on Wall Street and I can tell you my current one is the most efficient one. The process is pretty simple; just fill out one form including the location of the source code. Tarballs and git repos accepted. In fact I COULD dupe the last entry to create a new entry very easily. But the code has to be fetchable. Tarballs are fetched via their urls. Git repos by url and some version. Now, I could probably enter a naked commit ID to the system, but I absolutely don’t want to be entering a new record every two weeks just to grab some new functionality. I’d like to grab once and move on. -- Matthew O. Persico

[matthewpersico]

The automatic vetting includes confirming that there is a license file in the code and that the license is an acceptable Open Source one.

[matthewpersico]

And yes, the "owner" of the code internally is responsible for content evaluation.

[zemanlx]

It would be nice to get changes that are needed for stack 15.1 / ghc 8.8.2 into release so we can build on them.

[wknapik]

@koalaman while all of the above reasons apply, for me it's primarily about getting up-to-date shellcheck binaries without too much hassle (like building from source).

I execute my CI pipeline stages inside docker containers, which means I have two reasonable ways of getting the shellcheck binary - either by installing it from a distro package, or by doing something like this:

ENV SHELLCHECK_URL https://storage.googleapis.com/shellcheck/shellcheck-v0.7.0.linux.x86_64.tar.xz
RUN curl -fsSL -o- "$SHELLCHECK_URL"|tar -Jx "$(echo "$SHELLCHECK_URL"|grep -oP 'shellcheck-v\d+\.\d+\.\d+')/shellcheck" -O >"$EXEC_DIR/shellcheck"

Both methods require an official release.

I think the most relevant argument for more frequent releases is to allow distros (and by extension users) to keep up to date.

[arrowd]

A bit irrelevant to this thread, but what's difference between latest 0.7 release on Hackage and GitHub?

Github one was released 8 days ago, while Hackage one was released in July last year. And both of them have the same version.

[koalaman]

I've been meaning to post about that! See #1871

tl;dr: It's the same, I just want to start serving releases from GitHub rather than GCS. If your CI downloads an official binary release, please update the URL when you get a chance.

[arrowd]

That means, there will be no Hackage releases anymore?

[koalaman]

Hackage releases will continue as usual. This only affects precompiled binaries.

[arrowd]

Ok, glad to hear that!

[diederikdehaas]

Can we have a new release before Debian Bullseye is released?
Debian Sid now has version 0.7.1, but there have been 133 commits since.
The debian/watch file checks https://hackage.haskell.org/package/ShellCheck/distro-monitor but I'm assuming there's a (strong) correlation between releases there and releases/tags here.

Debian Bullseye's freeze policy can be found here: https://release.debian.org/testing/freeze_policy.html

[samueloph]

Debian maintainer of shellcheck here,

Due to the bullseye freeze, we are out of time to ship any new releases.

I'm not saying this to put pressure on upstream, and I will continue to provide new shellcheck releases under our backports repository for our stable releases (bullseye).

FWIW we can also check for github releases instead of hackage, but as I understood, hackage will be kept in sync.