Time for a new release?

[ghostsquad]

Last release was August last year. Time for a new release?

[glesica]

There are a couple PRs that we want to get included in the next release (see milestones), but yes, I agree that we ought to make that happen ASAP.

[vsimon]

nice! looking forward to the fixes made to assert.Eventually().

[ghostsquad]

Release twice?

[ghostsquad]

What's wrong with releasing as often as possible instead of waiting?

[glesica]

Nothing fundamental, and I'd like to get to a point where we release much, much more often, maybe even on every PR. At this point it's just caution. Maybe what we ought to do is jump to 2.0 to avoid breaking anyone relying on semver and then we can improve our processes and release cadence from there.

[jacob-pascual]

Please consider fixing #878 before cutting a release if you plan on cutting a minor version as #867 was a breaking change.

[boyan-soubachov]

IMO we should finish and merge all open PRs (within reason) that are open as of now and do not break backwards incompatibility to do a v1.5.0. This would give us a quick and smooth release whilst we work on the compat-breaking v2.0.0. changes.

Another option is to move to a cadence where we gather breaking changes and release a major version at a specific cadence (e.g. annually) whilst minor and patches are released more often (e.g. monthly/two-monthly, etc...)

[ghostsquad]

You could also release every time a PR is merged?

[boyan-soubachov]

I have nothing against that. As long as the time human requirements are negligible. 🙂

…

On 10 Feb 2020, at 15:42, Wes McNamee ***@***.***> wrote:  You could also release every time a PR is merged? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ghostsquad]

I'm interested to know what the release process is. Since this isn't a binary (and thus doesn't require distribution to brew, chocolatey, etc), I assume it's just a matter of creating a new release in Github.

I use standard-version which manages the changelog for a project I maintain (go-jira). It's pretty simple process.

install

npm i -g standard-version

cut release

standard-version
git push --tags

Finally, manually copy/paste text from changelog (for this new version) into the release on Github.

[boyan-soubachov]

You’re 💯 % correct 🙂. I think the bigger issue is just remembering to do it. Maybe a good solution would be to automate it with GitHub actions? Would that be feasible?

…

On 10 Feb 2020, at 17:07, Wes McNamee ***@***.***> wrote:  I'm interested to know what the release process is. Since this isn't a binary (and thus doesn't require distribution to brew, chocolatey, etc), I assume it's just a matter of creating a new release in Github. I use standard-version which manages the changelog for a project I maintain (go-jira). It's pretty simple process. install npm i -g standard-version Cut Release standard-version git push --tags Manually copy/paste text from changelog (for this new version) into the release on Github.com. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[glesica]

We have to manually determine the next semantic version, which makes it trickier. But it certainly can be done, maybe we could use labels on PRs, although I'm not sure if those are easily available inside GitHub Actions.

[boyan-soubachov]

IMO we should start with a simple PoC. I’ll only be able to look into it later in the week. If anyone else wants to I’ll be more than happy to lend a hand where necessary

…

On 11 Feb 2020, at 04:03, George Lesica ***@***.***> wrote:  We have to manually determine the next semantic version, which makes it trickier. But it certainly can be done, maybe we could use labels on PRs, although I'm not sure if those are easily available inside GitHub Actions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ghostsquad]

@glesica - enforcing conventional commits would solve this problem. As long as each commit follows the convention, which can be enforced during PR (part of travis build) with something like this:

https://prahladyeri.com/blog/2019/06/how-to-enforce-conventional-commit-messages-using-git-hooks.html

I'm happy to take a stab at this if no one else is interested.

[boyan-soubachov]

Fine by me, just be wary of the complexities introduced by git hooks.

If you choose the githook approach, we need to make sure they're smooth and painless for devs across Linux/MacOS/Windows :)