Defined release process?

[dsernst]

Is there a defined process to publish new releases?

Looks like the latest (v0.20.0) is from April 2018, over a year ago.

Since then, there have been dozens of PRs merged, and it looks like 181 commits to master. (Cheers, great work everyone. 🥂)

I'm particularly interested in seeing Remove (BETA) from app window title & Add YouTube style hotkeys shipped.

I do see Package the App instructions at the bottom of README.

(I'm happy to package new releases if that's the only blocker on this. Working from a beefy Mac so can build for all platforms, although obv don't have key to sign.)

[DiegoRBaquero]

We could distribute an unsigned version, as @feross holds the certs and keys, maybe he could share them with me, but only if webtorrent.io updates itself with the repo. Else we are still "blocked" by @feross to also update website.

Hopefully he sees this. If these are blockers we could setup an automated process.

[Borewit]

Thanks for your quick reply @DiegoRBaquero.

Can you help us moving on @feross?

[feross]

Hey everyone! I'm happy to do a release (and to do them at more regular intervals going forward). Is the current version on master in a shippable state? Which contributors have done most of the work on this release? Who is willing to own handling issues that arise after the new version goes out by monitoring the telemetry dashboard (i.e. if there is a bad bug, quickly working on a fix for a new release)? Is the changelog written up?

[Borewit]

Feross, I think releasing more often will encourage contributors.

I think the master is in a shippable state.

@mathiasvr has done a significant part of the changes. I hope @dsernst is willing to keep actively participating, as he has done a great job lately as well.

Much of the progress has been realized by a large number of contributors submitting small improvements.

I am willing to support addressing issues introduced by the new release on the condition we speed up the approval process of PR's. If I had to choose between risking a mistake slips in or loosing the interest of contributors, I would go for this first in the current situation.

ToDo:

• Update changelog

[feross]

Feross, I think releasing more often will encourage contributors.

I totally agree.

As most of you have probably gathered, I needed to step away from OSS for a while to rest and recover. I achieved a lot in a short time in the early days of WebTorrent by working really hard but I got totally burned out after several years of working on it full-time. (literally. I worked exclusively on WebTorrent and didn't even have a job to support me for many years). I now feel that I've recovered sufficiently to return with a healthier attitude. We'll see :)

I just want to emphasize how much I appreciate the work that you and all the other contributors have been doing while I've been away.

[Borewit]

I wasn't aware you had a burn out.

Let this be a wise lesson to all of you. Especially those hard workers among us, the boys and girls who do not plan to give up, who do the few extra miles every day to do things right.

I am happy to hear you are feeling better Feross.

[mathiasvr]

Just saw this now, good to see you're back @feross!

I haven't been very active in this repo for the past 6 months, but I believe @Borewit has done a great job and have a good overview of the changes during that period.

Quite a while ago I drafted a release with some of the changes (don't know if you can see it?),
but I will try to get it up to date. (Edit: Just opened #1635).

About the approval process of PR's, the major problem IMO is that it is more difficult for active members to get code merged than for other contributors. This is because PR's requires 2 reviews, but since a member cannot approve their own PR, we now actually need 3 active members to get it merged, which have rarely been available.

[feross]

I haven't been very active in this repo for the past 6 months, but I believe @Borewit has done a great job and have a good overview of the changes during that period.

Yeah, I've noticed that. Huge thanks to @Borewit!

Quite a while ago I drafted a release with some of the changes (don't know if you can see it?),
but I will try to get it up to date

I did see this. You put in the GitHub release notes, right? I actually just deleted that since CHANGELOG.md is actually the right place for it. The npm run package script will automatically create a GitHub release at packaging time using the release notes from CHANGELOG.md. :)

[feross]

About the approval process of PR's, the major problem IMO is that it is more difficult for active members to get code merged than for other contributors. This is because PR's requires 2 reviews, but since a member cannot approve their own PR, we now actually need 3 active members to get it merged, which have rarely been available.

I can change the setting so that only 1 review is required to merge. I think it would be best if we still waited for 2 approvals from team members for outside PRs that are not trivial. For PRs that come from a team member, only one approval should be sufficient.

We should also try to wait for a week or two for big changes, or changes that are likely to be controversial, so that everyone has a chance to see the PR and give feedback before it's merged (even if there's already enough approvals to merge).

Does this sound reasonable to everyone?

[Borewit]

For PRs that come from a team member, only one approval should be sufficient.

Yes please, I lost focus so ofton on pending approvals. Let's grab the momentum, and prevent loosing focus.

[feross]

Hey everyone, if it's okay with everyone I'd like to close this issue now. I made a new issue with some ideas to improve the release process: #1678