Repository navigation
Permission to start culling all pre-v4 infra and build logic #926
Description
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.
Activity
refack commentedon Oct 19, 2017
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 anode-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 commentedon Oct 19, 2017
Just remembered the
node-gypjobs use prebuilt node binaries by definition, so not a real issue.joaocgreis commentedon Oct 20, 2017
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_SUBSETright 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 commentedon Oct 24, 2017
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 commentedon Oct 24, 2017
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 commentedon Oct 24, 2017
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 commentedon Oct 24, 2017
mhdawson commentedon Oct 24, 2017
+1 from me.
rvagg commentedon Oct 26, 2017
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 commentedon Oct 26, 2017
I think we should just move forward with a recommendation.
gibfahn commentedon Oct 26, 2017
How would we do that? Issue in TSC repo? I'm happy to propose #926 (comment) as policy.
rvagg commentedon Oct 27, 2017
@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.
doc: note that release config is removed after 6m
doc: note that release config is removed after 6m (#997)