Please tag a new release

[AlekSi]

There are 42 commits since 1.3.

[julienschmidt]

And a few more will follow before we will tag another release.

If you feel brave, use the cutting-edge (master branch) and give feedback.
We made some larger functional changes during the current cycle, e.g. multi-results support (which should be rather stable now), and changes to the retry-logic (#302) which probably needs further adjustment (#657) before we can release it as stable.

You can speed up the whole process by contributing or just addressing general issues which distract us from getting the next release ready.
We are eagerly looking for more active contributors to this project. AFAIK all 3 of the current team members work on this exclusively in their free time. Unfortunately, none of us currently seems to have much time to spare.
If your (addressed to everyone reading this) company depends on it, my advise would be to make sure someone that gets paid to work on this regularly during work time.

[AlekSi]

If current master is less stable than v1.3 tag, then probably Installation section of README should mention that? Having an explicit versioning policy should be beneficial for users.

[djui]

What's the latest status on a potential v1.4 release? Are there any concrete issues making this release a problem? How could I help out to make a new release happening?

I believe you could just take the very latest commit as start of let's say v1.4. If people then use this version in their Dep config e.g. as version=^v1 or even version=v1.4 and find critical bugs, we could release v1.4.1 and users will implicitly get the bug fix; other than not cutting the release, people for FUD not relying on branch=master but rather revision=X and then very late realising there is a bug fix already available for them.