Update release process documentation

[UlisesGascon]

This is a new version for the documentation. It is based on the experience doing #5505 but with some tweaks.

Key assumptions

• We expect to use PGP to verify commits and releases (done by github mostly out-of-the-box)
• We expect to land most of the changes into master branch and pick the relevant commits once doing a release
• We can backport changes to the major branches (at any time) without managing releases so we avoid a lot of conflict management

Some notes

• This is based on the Node.js release process
• I don't think that this process is perfect, but it is an starting point that we can shape in the next releases for v4 and v4 and onboarding new releasers 👍
• I need to normalize the branches 4.x and 5.x in order to make this guide accurate (if you try to follow it in a fork o similar)
• The current release process was not working (out-of-the-box) when @wesleytodd and I reviewed, but feel free to rescue things and propose more changes.
• I will work on a separate Pr once this one is merged just to clarify how to do security releases, just to avoid having a mix guideline that can be more complex to follow.
• From this PR is expected to extract a consolidated way on how to land PRs (see step 4) that we can isolate in a separate guide "how to land PRs" 👍

[sheplu]

Great work, but I am not really convinced that the Express way / Node.js way is the good one here.
I just have one major question here, why are we not switching to using github release to do all the "hard work"? I guess we need less process than Node.js itself - this is how fastify is doing it it seems - and how I do handle my releases at work

A lot less maintenance, a lot less impact and manual workflow

• clic on "generate new release"
• choose your branche "v5"
• setup your tag "v5.3.2"
• clic on "generate release note" (update if you want)
• done

We can discuss that when you want, but for me this would be simpler, and it would be the same process for all packages (not just express)

[UlisesGascon]

I just have one major question here, why are we not switching to using github release to do all the "hard work"?

We actually do it on the step 7 (partially). If we work directly with the major branches we depend a lot on what is included there in terms of changes (minor, patch...) and it will be hard to select what we ship and when (specially thinking on v5/v6/v7 when we only have partial features, etc...

Also this can be challenging if we want to do just a security release fast (patching) as we will need to create more ad-hoc branches, etc...

We can discuss that when you want, but for me this would be simpler, and it would be the same process for all packages (not just express)

Also I don't expect this process to be the same for other libraries in the project.

[sheplu]

Also I don't expect this process to be the same for other libraries in the project.

that is my main issue, I am not seeing why this is not the same process. For me we should be able to deliver things quickly, like other framework that have multiple releases per months.

After all, in my eyes, Express is just "another library" so why not follow a more traditional /simplified way? (This process would be for the v5 - maybe not v4)

I am not seeing that we should create a new version every day but even if we have a security update, then let's push what's already merged (that was reviewed and validated, so it should be working)
Even if Express is huge, I don't think we need the same heavyness in the process than for a Node.js release. No specific need to announce before.

We could even say "Hey, every Monday, if there is something new we do a release if not let's see in a week". This way we have small and quick incremental changes.
For reference, back in the 2.x days Express had releases every couple weeks, some time even multiples times in the same week https://github.com/expressjs/express/tags?after=2.5.9

[joeyguerra]

Have y’all consider using the semantic-release tooling? I’m using it in Hubot.

[joeyguerra]

Should there be a link to the Slack account/channel?

[wesleytodd]

Great work, but I am not really convinced that the Express way / Node.js way is the good one here.

I think I agree with @sheplu on this, but I have to say seeing it in this form (as a pr changing existing docs) makes it REALLY hard to fully grok the differences. IMO this conversation would be a lot more clear it we had a plain issue write up of the proposal before a PR version. Because I am not sure we really have clarity on the differences and what the ideal even is, I feel like we should start with a new issue and outline 2 or 3 options for workflows we can compare.

[UlisesGascon]

thanks for all the feedback! I will work in an issue to present this version and a simpler one, so we can have a better high level discussion.

Also I need to include an step to update the website: (Ref: expressjs/expressjs.com#1469)