Permission to start culling all pre-v4 infra and build logic

[rvagg]

This is something that we should make explicit and get full buy-in from at least the Build team, (if not the TSC itself?). We have a bunch of pre-v4 stuff cluttering up our resources that, if we had explicit clearance to start removing, I think team members would happily start pulling out. The main bits I can think of are in Jenkins, there's a ton of logic around pre-v4 builds in the scripts we have and also for build node labels. There's at least one build resource I can think of (smartos) that is still only required for pre-v4 builds too.

To be clear, this would cover: v0.10, v0.12, and all of io.js. We're essentially precluding the ability to release, or even test off any of these old branches by approving this.

@nodejs/build please 👍 this issue or +1 in some way if you support this and give permission to clean house if anyone stumbles across anything that can be removed; otherwise please explain why you don't support it.

[refack]

Only issue I have is node-gyp@3.x.x. We are committed to support node > 0.8.0 with that branch, and we also haven't yet cut a node-gyp@4.0.0 (which drops node < 4).

I'm +1 on cleaning up hacks from Jenkins jobs.

BTW: when was the most recent pre 4 build done / what is the probability we'll have to cut another release?

[refack]

Just remembered the node-gyp jobs use prebuilt node binaries by definition, so not a real issue.

[joaocgreis]

Yes please. I would be very surprised if it all still works. Removing all that logic will make the jobs significantly cleaner and easier to edit. I haven't seen any pre-v4 jobs running in a long time.

This would allow us to remove NODES_SUBSET right away, I don't believe the target for docs only is used or usable now (full CI should run for every PR, I don't know why it was there in the first place). Ref: #696 (comment)

[rvagg]

Not sure if this is exactly the latest for pre-v4 but the last v0.10 was v0.10.28 on Oct 18 2016, the last v0.12 was v0.12.18 on Feb 22 of this year. io.js was last built on Sept 15 2015, that was v3.3.1.

So we're now 8 months past the last pre-v4 build and we've also been crystal clear that we don't support these any more, regardless of what security flaws there might be. Any builds of them by now is going to have to be unofficial and provided by a third-party. There was a time when some people (Mikeal most notable) were saying that "if you want to support old branches then you can put in the work and make it happen", but I've personally been advocating for a very clear line drawn on our release timelines so we don't cause uncertainty for users. And anyway, I've seen zero evidence of anyone wanting to use our infra to build old Node versions or even test them since we dropped the final v0.12—it was so decisive that I've not seen it questioned or challenged anywhere after it happened, it's a done deal.

[gibfahn]

I think this is a no-brainer , and we should just do it as standard policy. Maybe have a 6 month waiting period between EoL and removing from CI, so when 10.x goes LTS we remove 4.x from CI.

Of course this will be much less of a big deal once we get all our Jenkins config into git.

[rvagg]

OK, let's talk about this at our next meeting and then notify the TSC of our "recommendation" or "decision", however we want to frame it. They may have objections of course but we need to put the case forward with clarity.

[MylesBorins]

Huge +1

…

On Oct 24, 2017 7:27 AM, "Rod Vagg" ***@***.***> wrote: OK, let's talk about this at our next meeting and then notify the TSC of our "recommendation" or "decision", however we want to frame it. They may have objections of course but we need to put the case forward with clarity. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#926 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV9tByuNNwrOkWnT2HaBrWR3KkSK3ks5svcmegaJpZM4P_9gc> .

[mhdawson]

+1 from me.

[rvagg]

Oh, did this get discussed at the meeting yesterday after I left? Should we just move forward with a TSC recommendation, if they don't object in X days then we'll consider it a done deal?

[mhdawson]

I think we should just move forward with a recommendation.

[gibfahn]

I think we should just move forward with a recommendation.

How would we do that? Issue in TSC repo? I'm happy to propose #926 (comment) as policy.

[rvagg]

@gibfahn yeah, do that. How about you open a PR against our README with a note about such a policy and also add a tsc-review label to it and it'll be picked up in the next meeting and I, or Michael can speak about it.