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

Move 8.x into maintenance mode in January 2019 #376

Closed
MylesBorins opened this Issue Oct 24, 2018 · 10 comments

Comments

Projects
None yet
7 participants
@MylesBorins
Member

MylesBorins commented Oct 24, 2018

I was thinking. We are quite behind on backports for 8.x, and it has an end of life in December of 2019. Would we be better off moving it to maintenance mode in January 2019 and focusing our efforts on keeping 10.x up to date?

@mhdawson

This comment has been minimized.

Member

mhdawson commented Oct 24, 2018

I'd be ok with that option. It seems like if we have to choose between catching up on 8.x and falling behind on 10.x or keeping up on 10.x, keeping up with 10.x is a better choice.

@rvagg

This comment has been minimized.

Member

rvagg commented Oct 26, 2018

This is a shame, I'm not excited by this proposal, but given that I'm not currently actively contributing to backports for 8.x and we don't seem to be able to get more people to do it, it's hard to argue against this.

@AliSawari

This comment has been minimized.

Member

AliSawari commented Oct 30, 2018

how is it possible to have two active LTS releases at the same time? wouldn't that make some confusions for the new coming developers to choose? Also, what does Maintenance mode means? is that something like a Tag that indicates the final days of a release? what's the point of it? thanks in advance.

@mhdawson

This comment has been minimized.

Member

mhdawson commented Oct 30, 2018

@AliSawari we need to have overlap so people have time to transition from one LTS release to another.

Maintenance mode means that commits which have landed in master/Current releases are no longer actively backported to the version. Instead only Critical and security fixes are backported.

@AliSawari

This comment has been minimized.

Member

AliSawari commented Oct 30, 2018

@mhdawson Thanks for answering!
yeah I think you guys should keep up with updating 10.x
I think most of the user-base chooses the latest version, as 8.x been removed from the Node.js Main Page and replaced by 10.13.0 LTS. so its better to end its life earlier this time 😄

MylesBorins added a commit to MylesBorins/LTS that referenced this issue Nov 19, 2018

@richardlau

This comment has been minimized.

Member

richardlau commented Nov 21, 2018

This is a shame, I'm not excited by this proposal, but given that I'm not currently actively contributing to backports for 8.x and we don't seem to be able to get more people to do it, it's hard to argue against this.

I agree. I also wonder if we're not going to be in the same situation with 10.x and 12.x.

I'm assuming we'll be somehow communicating the change of date ahead of 1 Jan 2019 (so it's not a surprise to anyone not following this repository)? (It's too late, but maybe it should have been with the 8.13.0 release blog).

@MylesBorins

This comment has been minimized.

Member

MylesBorins commented Nov 21, 2018

I think we can start getting the news out ASAP once we land #391... part of the reason for landing this now was to give people over a month of a heads up

@MylesBorins

This comment has been minimized.

Member

MylesBorins commented Nov 21, 2018

re: 10 / 12... perhaps we should have a larger discussion about the timeline of our LTS plan

@boneskull

This comment has been minimized.

boneskull commented Nov 26, 2018

Was/is there a larger conversation around backporting somewhere? The impression I get is that it's often painful to do. I have a feeling it's also rather thankless work.

From the angle of the package maintenance initiative, it'd be good to collect some knowledge around what works and what doesn't.

related, @MylesBorins I'm not available to help with Node.js releases atm, but I'd like to be a fly on the wall for a future discussion around LTS timelines to better understand what goes into these decisions.

@dshaw

This comment has been minimized.

Member

dshaw commented Dec 6, 2018

@boneskull There were major calls to recruit releasers at both collaborator summits this year. @MylesBorins has been bearing most of the burden of backporting for a couple years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment