Repository navigation
Node.js v4 Release Timeline #2522
Description
Activity
This looks solid. +1
On Aug 24, 2015 6:37 AM, "Rod Vagg" notifications@github.com wrote:This is ultimately up to @nodejs/tsc
https://github.com/orgs/nodejs/teams/tsc but for the sake of just
getting it done I'm going to propose the way forward and will both tag
this as tsc-agenda and ask that @nodejs/tsc
https://github.com/orgs/nodejs/teams/tsc members comment on this
thread, particularly if they'd like to -1 anything I'm
suggesting—otherwise let's roll with this.Our original aim was to get v4 out by the "end of August" so that we had a
good 2 months of real-world use of v4 before it turned into LTS at the end
of October. We really need to hit the end of October window for LTS so the
longer we can have v4 out the better the chance of having a solid
combination of features as we lock down what can be changed during LTS.io.js v3 is doing a great job at being an alpha for Node.js v4 but it's
adoption is limited and it will only be when we have a new Node.js out that
we'll get an increase in usage. Thankfully there are already great efforts
to update popular add-ons to NAN 2.
Core tasksManaged by the 4.0.0 milestone
https://github.com/nodejs/node/milestones/4.0.0- [Converge] MSI related changes #2520 / [Converge] MSI related changes windows
[Converge] MSI related changes #2520 - [Converge] merge CHANGELOG.md with joyent/node ChangeLog #2519 / [Converge] merge CHANGELOG.md with joyent/node ChangeLog doc
[Converge] merge CHANGELOG.md with joyent/node ChangeLog #2519 - [Converge] copy relevant git metadata from joyent/node #2518 / [Converge] copy relevant git metadata from joyent/node
[Converge] copy relevant git metadata from joyent/node #2518 - [Converge] Re-enable mdb #2517 / [Converge] Re-enable mdb c++
[Converge] Re-enable mdb #2517 - build: use build_release target in vcbuild.bat to build releases #2516 / build: use build_release target in vcbuild.bat to build
releases build build: use build_release target in vcbuild.bat to build releases #2516 - [Converge] child_process argument type checking #2515 / [Converge] child_process argument type checking child_process
[Converge] child_process argument type checking #2515 - [Converge] SSLv2/3 related commits #2514 / [Converge] SSLv2/3 related commits tls
[Converge] SSLv2/3 related commits #2514 - win,msi: Upgrade from old upgrade code #2439 / win,msi: Upgrade from old upgrade code install windows
win,msi: Upgrade from old upgrade code #2439 - process.send() is not synchronous #760 / process.send() is not synchronous child_process confirmed-bug
process process.send() is not synchronous #760
Website migration tasks
Listed and tracking here: nodejs/build#163
nodejs/build#163@nodejs/website https://github.com/orgs/nodejs/teams/website
@nodejs/evangelism https://github.com/orgs/nodejs/teams/evangelism are
there other issues where you are tracking progress and do we have
everything captured in @ @nodejs/build
https://github.com/orgs/nodejs/teams/build that you need?
Release procedure tasksThis is needed because once we get to a new server for nodejs.org we need
to ensure we can put proper 0.10 and 0.12 binaries on it and and existing
users have a seamless transition.Listed and tracking here: nodejs/build#164
nodejs/build#164
TimelineDays are in Pacific Time, I think most of us are used to thinking that
way.Friday, 28th of August:
My proposal is that we adopt a feature freeze at the end of this week,
i.e. midnight, Friday the 28th PT. This means that everything that's
semver-major semver-majorPRs that contain breaking changes and should be released in the next major version. or
semver-minor semver-minorPRs that contain new features and should be released in the next minor version. that is
going to make it in to v4.0.0 needs to be landed by then.Also, cut a v4.x branch and start the cherry-pick process like we're
doing for v3.x.Monday, 31st of August:
DNS changeover to the new nodejs.org http://nodejs.org site, ensuring
consistency for users of /dist/, /api/ and other endpoints that are in use,
but with new.nodejs.org https://github.com/nodejs/new.nodejs.org code,
on new infrastructure, hopefully on a CDN, and able to accept releases
of all active lines of Node.js (0.10, 0.12 and v4 RCs) and io.js (v3 and
possibly v2 kept alive if we have a call for it) (i.e. it should also
serve iojs.org so we don't have to ship binaries to different locations
just for that).28th of August to 3rd of September:
A series of release candidates, made available, first at
https://iojs.org/download/rc/ and then http://nodejs.org/download/rc/
after the DNS changeover and nodejs.org is being served off a the new
server, to test the release procedure and make have testable builds that we
can try out.Changes that are not semver-major or semver-minor can still be
cherry-picked into v4.x but we should become increasingly strict as the
week progresses in the interests of having a solid v4.0.0.Thursday, 3rd of September:
Release v4.0.0.
If, for some reason, we fail to get it out by end of day on Thursday,
Pacific Time, we'll postpone the release until Monday, 7th of September soas to avoid the pain of a weekend release.
Again, this is a proposal but unless there is objection from @nodejs/tsc
https://github.com/orgs/nodejs/teams/tsc, let's treat it as the plan
so we can ship this thing.—
Reply to this email directly or view it on GitHub
#2522.- [Converge] MSI related changes #2520 / [Converge] MSI related changes windows
LGTM
I love this plan. LGTM
As some would say. Amazeballs.
Is «midnight, Friday the 28th PT» (feature freeze)
2015-08-28 00:00:00or2015-08-28 23:59:59? Doesn't seem clear to me.I hate feature freezes. Can we say that the v4.x branch is cut on the 28th and only gets bug fixes from then on but that master is still FFA?
Think that's what is meant. The v4.x branch won't be receiving any changes, only fixes, until it's released. Changes will continue to land as normal on master. Basically, our current workflow won't change.
+1
@bnoordhuis you're not the first person to object to my use of the term "feature freeze" here, really what I'm getting at is that all of this stuff should be landed by then: https://github.com/nodejs/node/milestones/4.0.0, cutting a
v4.xbranch will help with that. This is OSS so there's no PM breathing down our shoulders who will yell at us if we land a major change in the last couple of days but I'd really like us to focus on getting the important stuff landed this week and cut our losses if we can't.I have no objection but let me confirm that LTS starts 1st Oct. but feature freeze and only bug fix for v4.0 branch start from 3rd Sep. What is the difference? Is there any purpose to be 4 weeks ahead?
Actually you're right, start of October according to https://github.com/nodejs/LTS/, I've had end of October in my head all this time for some reason, so that gives us even less time to get this right!
So If there is no actual meaning of LTS starting in Oct., I think it is better to say that LTS starts form the date of the release of 4.0.0, 3rd Sep. but we need not change the end of LTS.
So If there is no actual meaning of LTS starting in Oct.
LTS means less stuff lands into it, since 5.0 will be stable, and there will be a master for 6.0
107 remaining items
👍 🎉 🎈
+1,000,000 internets
Yay. Party Hard.
Yesssss..... :-)
+1!!!! Thank you for every collaborator/tsc hard work.
Congratulations!
Good job and thanks everyone!
Good stuff! Good job everyone!
Congratulations!!!
Thanks for your hard work everyone 👍
Maybe the wrong place to comment here, but is this the same team that works on the dockerhub images? Would we be able to expect that soon?
It's coming: nodejs/docker-node#42
Hopefully we can get it in the registry this week.
awesome work 👍
👍 this is so awesome
This is ultimately up to @nodejs/tsc but for the sake of just getting it done I'm going to propose the way forward and will both tag this as
tsc-agendaand ask that @nodejs/tsc members comment on this thread, particularly if they'd like to-1anything I'm suggesting—otherwise let's roll with this.Our original aim was to get v4 out by the "end of August" so that we had a good 2 months of real-world use of v4 before it turned into LTS at the end of October. We really need to hit the end of October window for LTS so the longer we can have v4 out the better the chance of having a solid combination of features as we lock down what can be changed during LTS.
io.js v3 is doing a great job at being an alpha for Node.js v4 but it's adoption is limited and it will only be when we have a new Node.js out that we'll get an increase in usage. Thankfully there are already great efforts to update popular add-ons to NAN 2.
Core tasks
Managed by the 4.0.0 milestone
Website migration tasks
Listed and tracking here: nodejs/build#163
@nodejs/website @nodejs/evangelism are there other issues where you are tracking progress and do we have everything captured in @ @nodejs/build that you need?
Release procedure tasks
This is needed because once we get to a new server for nodejs.org we need to ensure we can put proper 0.10 and 0.12 binaries on it and and existing users have a seamless transition.
Listed and tracking here: nodejs/build#164
Timeline
Days are in Pacific Time, I think most of us are used to thinking that way.
Friday, 28th of August:
My proposal is that we adopt a feature freeze at the end of this week, i.e. midnight, Friday the 28th PT. This means that everything that's
semver-majororsemver-minorthat is going to make it in to v4.0.0 needs to be landed by then.Also, cut a
v4.xbranch and start the cherry-pick process like we're doing forv3.x.Monday, 31st of August:
DNS changeover to the new nodejs.org site, ensuring consistency for users of /dist/, /api/ and other endpoints that are in use, but with new.nodejs.org code, on new infrastructure, hopefully on a CDN, and able to accept releases of all active lines of Node.js (0.10, 0.12 and v4 RCs) and io.js (v3 and possibly v2 kept alive if we have a call for it) (i.e. it should also serve iojs.org so we don't have to ship binaries to different locations just for that).
28th of August to 3rd of September:
A series of release candidates, made available, first at https://iojs.org/download/rc/ and then http://nodejs.org/download/rc/ after the DNS changeover and nodejs.org is being served off a the new server, to test the release procedure and make have testable builds that we can try out.
Changes that are not
semver-majororsemver-minorcan still be cherry-picked intov4.xbut we should become increasingly strict as the week progresses in the interests of having a solid v4.0.0.Thursday, 3rd of September:
Release v4.0.0.
If, for some reason, we fail to get it out by end of day on Thursday, Pacific Time, we'll postpone the release until Monday, 7th of September so as to avoid the pain of a weekend release.
Again, this is a proposal but unless there is objection from @nodejs/tsc, let's treat it as the plan so we can ship this thing.