Time for a new release? #879
Comments
|
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. |
|
nice! looking forward to the fixes made to assert.Eventually(). |
|
Release twice? |
|
What's wrong with releasing as often as possible instead of waiting? |
|
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. |
|
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...) |
|
You could also release every time a PR is merged? |
|
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.
|
|
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.
npm i -g standard-version
standard-version
git push --tagsFinally, manually copy/paste text from changelog (for this new version) into the release on Github. |
|
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.
|
|
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. |
|
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.
|
|
@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: I'm happy to take a stab at this if no one else is interested. |
|
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 :) |
|
@boyan-soubachov I could certainly introduce something like https://pre-commit.com/ which would allow folks to install a standard set of git hooks when they are contributing, however strictly speaking, that's probably out of scope. It can be easily added later though. Since pre-commit allows Please correct me if I'm wrong, but the scope of this work should be:
The only question I have is whether or not you want to support Squash Merging? If not, then all commits for a PR must follow the pattern. Else, special care must be taken by the maintainer to maintain the correct commit message when squashing the PR commits via the GitHub UI. |
|
I'm indifferent to squash vs merge. Both have pros and cons, maybe a good idea would be to compare them after we implement the PoC and see what works better? I would try and avoid commit hooks for now if we can though and rather start with just getting some pipeline going that will make creating new releases easier. Once we have that going, we should then look at the best way to automate it :) IMO an iterative approach makes more sense here since there are quite a few variables and unknowns @glesica , thoughts on this? |
|
I like linear history, so I'd recommend rebase merging. AFAIK, the only current downside to that is that verified/signed commits would no be longer be signed in master, since Github has to recreate the commit. |
|
@ghostsquad , your call :) If you have a PR we'd be happy to look at it and help you get it merged. |
|
The "Next" milestone says that "This is likely to be 2.0.0". Would it be possible to release a patch version first with fixes, for example, from #808? |
|
I'm fine with releasing 1.4.1 or 1.5.0 before 2.0.0 but someone needs to figure out which changes are safe to release in that form and then do whatever Git magic ends up being required to make that happen (possibly just make a branch, cherry pick the commits that aren't breaking, and then we can tag that branch). In the future, we should probably start using a "develop" branch or something along those lines. The fact that we merge into, and release from master is probably an artifact of Go's previous lack of formal dependency versioning ( Unless someone wants to take this on, the next release is going to be 2.0.0 because I don't have time to fiddle around with it. |
|
@glesica , I’d be happy to do the 1.5.0 release. Will get around to it in the next week or two
… On 19 Feb 2020, at 03:16, George Lesica ***@***.***> wrote:
I'm fine with releasing 1.4.1 or 1.5.0 before 2.0.0 but someone needs to figure out which changes are safe to release in that form and then do whatever Git magic ends up being required to make that happen (possibly just make a branch, cherry pick the commits that aren't breaking, and then we can tag that branch).
In the future, we should probably start using a "develop" branch or something along those lines. The fact that we merge into, and release from master is probably an artifact of Go's previous lack of formal dependency versioning (go get grabbed master, so merging changes into master was basically equivalent to a release).
Unless someone wants to take this on, the next release is going to be 2.0.0 because I don't have time to fiddle around with it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
v1.5.0. is officially out. @ghostsquad , if you still want to look at automating the process a bit, let me know, I'd be happy to help :) |
|
For now, I'm closing this issue. |
Last release was August last year. Time for a new release?
The text was updated successfully, but these errors were encountered: