Faster Major Release Schedule

[wesleytodd]

I think we need a faster major version release schedule. The problems we are having with the 5.0 branch getting released is that it is taking on too much at once. But, there are no better options right now because the current release cadence is so slow that not making it in 5.0 would mean pushing breaking changes off for many years. I think this will halt progress in many areas of the project, and would be fixed by running more majors more regularly.

I think end users would be happy with majors with breaking changes once a year. Two to three times a year is reasonable for most people if the changes don't require major code updates. Anything more than that is unreasonable, but I also don't think we would want that much to change in express anyway.

With this proposal, I think we could move some things which are pending for 5.x into a 6.x branch, and move the release date for that much sooner. Then we could set the planned 6.x for early to mid 2019. Although we wouldn't actually need to do that if others disagreed, but it would get the promise support, dependency upgrades and other existing changes out much sooner.

Thought?

[dougwilson]

So I am out on my phone so hard to really type out my full thoughts here, but wanted to write down some of the ones at the top of my mind for discussion.

I have no issues with major releases (aka breaking changes which is the only thing that would trigger them).

There are a few things that needs to be balanced with whatever the plan is:

1. how often to release breaking changes
2. how long to continue supporting a major after the next version is released
3. how to field confusion and marketing with breaking things (i.e. even when a user comes to open an issue about a tutorial no longer working, how can we quickly identify that they need to use an older version and how to correct the issue to prevent endless issues being opened)
4. fragmentation
5. probably others but just hammering out some quick thoughts.

Also, in all these years, I have never worked somewhere that upgraded something just for the sake of introducing random risk into an existing working project. Literally stuff I find in various companies to this day are on Node.js 0.x versions. Companies using the newer things and trying to keep up struggle to even keep on the current LTS before it's support expires.

In my mind, it would seem a two year cycle would have the best balance between all the factors, with the previous version being supported for 2 years after new as well.

Idk, though, and it's a tricky topic. I have seen some folks who moved from express to hapi only to return back to express for the specific reason of it being too hard to (1) just be on the current version and (2) internally keep all their projects on the same version so they were not fragmented.

For perspective where I am working right now there are 378 distinct express apps. Think about the man hours a company would expend to upgrade them breaking change, haha.

There are things that can mitigate this , of course, but require investment from somewhere. Things like a program that could automatically rewrite your app to fix things that don't need a human (think eslint --fix). There is a lot of that just in the current 4 to 5 so it's not like that wouldn't be valuable at some level, haha.

[dougwilson]

And to add: right now we don't actually have a release schedule at all, so it's hard to really say the current one is slow since it doesn't exist. Just wanted to frame it that we should actually have one in general. I think having one, no matter what it is, would be "faster" than the current one, just from the removal of the uncertainty that comes with there not being one, haha.

I like a lot of the ways Node.js has been doing their releases and stuff these days, except from the guarantee that there is going to be a release. The Express.js surface area is much smaller than express so I feel like a guaranteed major would likely quickly run out of steam and just change for the sake of it, which is never great.

Maybe ours would be like a minimum time frame kind of deal like if it was "once a year" for instance it really means "no more than one per year" instead of there literally being a new major version every year if there wasn't something to actually warrant it.

I do think that previous version support times would be based off when the next major version came out and not based on the release date of that major (though it could be a combo of the two, for instance).

[wesleytodd]

I attempted to consolidate and complete some of this in an ADR form. I am going to close this one out, so we can hopefully move all the conversation to one place going forward. If I missed anything from here please help me find and add it there because there is a lot of conversation and I am sure I probably missed something of it in my attempt to re-read and consolidate it.

#352