Node 4 EOL is on April 30th, not April 1st

[not-an-aardvark]

I realized I made a mistake when reading the Node release schedule -- the EOL date for Node 4 is April 30th, not April 1st. (I had accidentally been looking at the "Maintenance LTS Start" column rather than the "End-of-life" column.)

In today's TSC meeting, we decided to start doing prereleases for ESLint v5 on March 16th, but that decision was dependent on the assumption that the EOL date was April 1st. We might want to reevaluate that decision based on the corrected EOL date.

I've added the "tsc agenda" label to this issue to make sure we discuss it by the next meeting, but I'm hoping we can make a decision sooner by discussing it on this issue, because if we do the first prerelease on March 16th, we will probably want to merge some breaking changes before March 15th (the date of the next meeting).

cc @eslint/eslint-tsc

[btmills]

@mysticatea mentioned wanting to get #9893 into 4.0.0, if we delay the pre-releases it would give us time for that.

[not-an-aardvark]

A few things to consider:

• The release process for ESLint v4 lasted about 11 weeks between the first alpha and the first stable release. If v5 takes a similar amount of time, then the stable release will already be after April 30th anyway.
• The breaking changes scheduled for v5 seem more stable than the ones from v4 (i.e. we aren't rewriting indent), so ostensibly the v5 release process might take less time than v4.
• Doing a release later would give us more time to land features in v4.

I think I'm slightly leaning towards doing the first prerelease on March 16th anyway, because that is still fairly close to the EOL date (3 release cycles, assuming we continue with a prerelease every two weeks). But I'm not opposed to moving the date back if we want to get more features into v4.

[ilyavolodin]

I think we can safely delay a first pre-release by another two weeks. One thing that we should try to fix before first pre-release is versioning for rules index file for our website. When we were doing alphas/betas for version 3, I had to manually copy that file with every release, which was a bit annoying.

[mysticatea]

Currently, we support all ES2018 syntactic features on espree, but not on core rules. I'm happy if the last 4.x version supports it on core rules, too. But I'm not sure if we can implement it on the last 4.x version without oversights and we don't backport bug fixes to older major versions. So... I'm OK with either way.

[platinumazure]

I would love to get eslint-canary fully working and my ajv upgrade prepped before pre-releases, though I could see an argument for actually merging the ajv upgrade in a major release if we aren't sure it won't break someone. (Personally, I'm pretty confident the change won't break anyone but also would love to prove it via eslint-canary.)

[not-an-aardvark]

What would everyone think about doing the first prerelease on March 30th, and starting to merge breaking changes after this release cycle (i.e. next week)? This would probably allow us to fix #9893 in v4.x, although probably not #9856 since the TSC meeting today was cancelled.

There are also some minor breaking change proposals that haven't been accepted yet, including the question of which Node versions to support specifically. (We know we're dropping support for Node 4 and 5, but there is some debate about whether we will explicitly support versions like 7.x and 6.0.0.) We could make those changes in a second alpha release after they are discussed at the next TSC meeting.

Please 👍 this comment if you're in favor of doing the release on March 30th, or feel free to 👎/continue the discussion if you have concerns.

[btmills]

In addition to my 👍, not meeting #9856 into 4.0 could be perceived as an advantage since there’s a slight chance it’s a breaking change - we’d get to avoid that question altogether.

[not-an-aardvark]

It looks like there is a consensus about doing the first prerelease on March 30th based on the 👍s on #10041 (comment), so I'll close this issue.