Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added Status Board to adopters list #2

Closed
wants to merge 1 commit into from
Closed

Added Status Board to adopters list #2

wants to merge 1 commit into from

Conversation

jameswlane
Copy link

No description provided.

@CLAassistant
Copy link

CLAassistant commented Jul 25, 2018

CLA assistant check
All committers have signed the CLA.

@seabaylea
Copy link
Member

Hi James.

This is awesome, thanks. In terms of the LTS timeline for Status Board, the only entry you should need at the moment is:

Module Version Release Date Minimum EOL EOL With Status
1.x.x Nov 2017 Dec 2019 Current

As 1.x is the current release, that needs to be marked as Current or LTS for at least the lifetime of the most recent LTS version on Node.js - ie, Node.js 8 until Dec 2019.

If Status Board is still in version 1.x.x once Node.js 10 goes into LTS in October, then the Minimum EOL date would change to April 2021 (the EOL date for Node.js 10).

Does that make sense?

@jameswlane
Copy link
Author

@seabaylea It makes sense, and I updated the README.md based on you suggestions.

@seabaylea
Copy link
Member

Hi @jameswlane. Thanks for the update.

Technically your "Current" release should have a minimum EOL with Node.js 8.x (as the latest current LTS version of Node.js), and therefore a date of December 2019.

If your happy to update that, I'll get this merged and socialise that Status Board has adopted LTS via Twitter/Blog, etc.

@jameswlane
Copy link
Author

@seabaylea I plan on maintaining only a single version of Status Board, due to that I was planning a 2.0 release when 6.x.x reaches EOL and a 3.0 release when 8 reached EOL.

@seabaylea
Copy link
Member

Hi @jameswlane. The value of providing LTS is so that users don't have to immediately adopt a new major version when it becomes available - they can wait until the point that they have to do a migration anyway (when they have to update Node.js itself).

Under the releases and timeline that I think you're suggesting, you'd have the following release dates:

Module Version Release Date EOL
1.x.x Nov 2017 April 2019
2.x.x April 2019 Dec 2019
3.x.x Dec 2019

The challenge here for users is that there's no overlap - if they are using v1.x, in April 2019 they will have to switch to v2.x. Whilst for users of Node.js 8 that will align with them having to migrate anyway, that won't be true of users of Node.js 10.

@jameswlane jameswlane closed this Dec 18, 2018
@jameswlane jameswlane deleted the patch-1 branch December 18, 2018 02:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants