Releases

[CSimpiFoN]

Can't you guys create releases? It would make a bit easier to get a certain version of the module, also, no Git is needed, a curl or wget can download it.

[eustas]

Do you mean binary releases? Or source tarball is also OK?

[dvershinin]

I think we, packagers all need releases - a well defined tagged version that can be used as a reference to some stable version, or otherwise as a reference to a working version. There is a need for a formal version, e.g. 0.0.1 (IMHO, source tarballs only are just fine).

Considering that this fork has been packaged by quite many, I suggest releases here to start from e.g. v0.1.3 to "continue" the version line from the most-often packaged fork.

[carlesjavierre]

@dvershinin That's essentially the main reason I can't figure out if any commit that is done affects anything that i've made (config-wise, or bug-wise).

In my case, if my Dockerfile has an nginx build and I plug it in via git clone. I'll never get the same version of brotli unless I specify a commit (not visual). Not as easy as just downloading a versioned release (tars are fine), in which we trust and we see if it's stable, get changelogs, etc. We all need to be sure we're getting a "stable" release at least.

Also, some people like watching for releases (like me) to see if you already fixed #80 (for example), instead of following the whole project. (yeah that was a small attention intent into that issue)

[Jas0n99]

Or source tarball is also OK?

IMO, just a tarball release is fine. Something to define clear stable points and update changes for people.

[lenovouser]

Any update?

[eustas]

Hopefully this week =)

[eustas]

v1.0.0rc is out. Will cut v1.0.0 after dealing with existing PRs and issues.
Also planning to migrate to "Github Actions" instead of travis.