meta: updated messaging regarding dates

[MylesBorins]

Currently our schedule specifies exact dates, this can be hard to
commit to. If we plan to be flexible with the dates we chose when
moving a release stream between different levels of support we should
be explicit about it.

This removes all future dates that have currently been decided,
alternatively offering a month in which the event will take place.

It also adds some new language the outlines when individuals should
expect us to give them a date.

• No later than the first of the month the change is happening
• No less than 14 days before the change is happening

I believe that this contract is reasonable and much less likely
to cause miscommunication in the future.

One thing not mentioned in here is how we will be communicating these
dates, and potential changes. We need to decide on a single communication
channel and stick to it. Very likely it can be the blog, but we should
discuss this first.

[jasnell]

Lgtm

[nathanhammond]

This seems fine. Maybe some wordsmithing still to make it clear, but I know the intent because of our conversation.

That being said, dropping of support on specific dates seems less constraining than specifying start dates. They will always simply be arbitrary lines in the sand. I'm unsure why we can't simply select one.

The only reason to make them coincide with releases would be to make it possible for migration to a new version–but nobody should reasonably attempt to move from a fully EOL LTS to whatever Node.js version is being contemporaneously released as that's a bad technical decision. Even if you said that it was to trail the new release by N days it's a bad technical decision because you don't know what issues you may encounter and you shouldn't expect to be able to solve them in 7-14 days. (Thus the months-long overlap periods in the existing schedule.)

[nathanhammond]

Hrm. There are four transitions that matter:

1. Current to Active.
2. Active to Maintenance.
3. Maintenance to EOL.
4. Current to EOL.

My previous comment only addresses transition 3 (and possibly transition 4). This language is certainly needed for the other transitions (which simply aren't relevant with our approach in the Ember community).

So I propose that final EOL (transition 3) has a date attached when transition 1 occurs. Transition 4 has a date set when that unstable version is released. And transitions 1 and 2 follow the pattern proposed by this PR.

[MylesBorins]

@nathanhammond I'm going to have to think about this for a bit. If I am following you correctly you are saying that the only date that should be set, and set FAR in the future is the EOL date, which should be decided when a release goes from Current to Active.

At this current time my gut is telling me that this date needs to be flexible as well. Here is a quick breakdown of the security releases we had to do last week.

• Thu 22 we are notified of CVE's
• We plan for a release on the 27th, including the openssl CVE as well as some other vulnerabilities that we are patching
• On Monday the 26th a more severe CVE is released, caused by the last update
  • this did not affect the 1.0.1 line that 0.10 is on, but these things happen
  • these were fixed before we even did a release, no Node release was never vulnerable

I don't feel that it would be particularly responsible to EOL v0.10 less than a week after these changes have landed. It is important to have this kind of flexibility, and as such it seems that choosing a date, that is subject to change, gives the wrong message.

Is a date range of a month too broad for your needs?

[nathanhammond]

Is a date range of a month to broad for your needs?

Nope. I'm pretty easy to please as long as we communicate dates and are able to plan on our side. (So the rest of this comment is just opinion that I don't mind being overridden.)

... EOL v0.10 less than a week after ... changes have landed.

If everybody has been expecting the EOL on a particular date then they should already have their lifeline in place: some newer version of Node.js. I also don't see a problem with a release after Maintenance ends for conscience reasons, but the community libraries will have moved on.

If a CVE shows up in your inbox one day before drop of support do you release a new version? One hour? Does every new CVE trigger a push of the sunset by N days?

If we can't reasonably get a release out before the sunset date of that Node.js version my (harsh) opinion is "then never patch it." We promised support up until that date and no longer; the user should have been prepared to jump to the next version.

I also always assume that hacking groups sit on zero-days until the day after support ends for particular software versions. With that mindset patching something days or hours before dropping support simply means that it's safe until the day after we stop supporting it.

[mhdawson]

I'm thinking we can set the Maintenance to EOL as a fixed date as well. If for some exceptional reason we believe we need to cut a release after that then I don't think that prevents us from doing that.

[mhdawson]

@MylesBorins I think this is waiting on an update or response from you.

[MylesBorins]

So it looks like this never got discussed in an LTS meeting. Lets discuss this in the next one and land it

[gibfahn]

This was discussed in the last LTS meeting and there were no objections, so this is good to land.

[gibfahn]

of the month it is -> of the month. It is

[gibfahn]

Needs a rebase, but LGTM

[MylesBorins]

rebased and updated based on new calendar. Can people please take a look

[gibfahn]

While you're here, is there a reason these are v0.10 and v0.12 instead of 0.10.x and 0.12.x?

[mhdawson]

LGTM