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

v5.0.0 Planning & Checklist #3397

Closed
rvagg opened this Issue Oct 16, 2015 · 13 comments

Comments

Projects
None yet
7 participants
@rvagg
Member

rvagg commented Oct 16, 2015

Items that have been tagged for the 5.0.0 milestone, with the people that added them:

Please update the issues to reflect current status so we can tick off the milestone. If it is a real blocker then keep it there, if it can be resolved then please try and do so, if it can be pushed then please add to 6.0.0.

Additional items to do that I can think of now:
A branch has been created and master has had its version bumped to 6.0.0.

  • Create a v5.x branch - this has been done
  • Bump master to 6.0.0
  • Turn on nightly builds for the v5.x branch
  • Bump NODE_MODULE_VERSION
  • Create release candidates
  • Display v5.x along with v4.x LTS on the website, discussion on this is happening here, I'm suggesting that @phillipj take ownership for ensuring this gets done, in some form
  • Update ES6 documentation for V8 4.6 (I think @trevnorris suggested it was outdated already for v4.x but I haven't looked to confirm).
  • RELEASE THE KRAKEN

"Early next week"

@rvagg rvagg added this to the 5.0.0 milestone Oct 16, 2015

@rvagg rvagg referenced this issue Oct 16, 2015

Closed

Discussion: LTS & v5 release planning #3000

7 of 8 tasks complete
@rvagg

This comment has been minimized.

Member

rvagg commented Oct 16, 2015

Nightlies should be enabled now, first one for v5.0.0 is available here: https://nodejs.org/download/nightly/v5.0.0-nightly20151016676e61872f/

The neat thing about this is that with the new node-gyp@3 awesomeness, native addon compiles are properly supported, so you can actually use nightlies and RCs to do real work. I'm running this nightly now and it's working just great:

$ node -pe process.versions
{ http_parser: '2.5.0',
  node: '5.0.0-nightly20151016676e61872f',
  v8: '4.6.85.25',
  uv: '1.7.5',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '56.1',
  modules: '46',
  openssl: '1.0.2d' }

Windows binaries and installers are missing. We still have ICU download dramas with those slaves, will hopefully be rectified once #3399 goes in, until then there's a random chance we'll see Windows binaries turn up in nightlies. ARMv6 builds are also not there, I manually killed that job because I wanted to restart Jenkins and didn't want to have to wait 6 hours.

Nightly builds are scheduled for 11pm UTC, since the date on them is UTC-based. They will only build if there are fresh commits since the last nightly. The process should be automatic and the files will show up in https://nodejs.org/download/nightly/ when they are built, not all at once though like release builds, as they are compiled.

@jasnell

This comment has been minimized.

Member

jasnell commented Oct 16, 2015

The ICU download drama is becoming a bit irritating. To be absolutely honest, I'm not certain that it makes sense to continue keeping ICU out of the source tree -- or even making it optional in the build. It ought to be merged in just like the other dependencies and make a normal, non-optional part of the build / distribution.

@orangemocha

This comment has been minimized.

Member

orangemocha commented Oct 16, 2015

The reasons why I tagged #2672 and #2669 for 5.0.0 is because it was the agreed standard protocol for marking tests as flaky. We basically wanted to make sure that those test failures didn't disappear from our radar.

We still have a bunch of flaky tests and saying that these issues are blocking for the 5.0 release doesn't sound realistic. Should we kick the ball to 6.0.0?

@mscdex mscdex added the meta label Oct 16, 2015

@rvagg

This comment has been minimized.

Member

rvagg commented Oct 17, 2015

@jasnell I'm actually less concerned by the ICU stuff once we get this --download-path thing sorted out, we can then enable ICU for test runs too.

@orangemocha I guess it makes sense to bump to 6.0.0 although we probably should explore ways to get these flaky tests properly sorted out rather than letting them linger. Perhaps we need to enforce a "no more merging until the flaky tests are sorted out" hammer at some point!

@orangemocha

This comment has been minimized.

Member

orangemocha commented Oct 19, 2015

@rvagg : I agree that we need a better process to get traction on these flaky tests. I will bump those issues to 6.0.0 for now, but open an issue to discuss the process.

@rvagg

This comment has been minimized.

Member

rvagg commented Oct 21, 2015

Updated checklist in OP to be accurate and tick some things off

@phillipj

This comment has been minimized.

Member

phillipj commented Oct 21, 2015

Necessary website changes to the front and download pages has been proposed with nodejs/nodejs.org#260 and nodejs/nodejs.org#261 respectively.

@evanlucas

This comment has been minimized.

Member

evanlucas commented Oct 21, 2015

Does nan need to be updated for this?

Also, I made some updates to the ES6 page as well (nodejs/nodejs.org#268)

@Fishrock123

This comment has been minimized.

Member

Fishrock123 commented Oct 22, 2015

I landed ecab7a6 repl: event ordering: delay 'close' until 'flushHistory' -- but it may be worthwhile smoke-testing it...

cc @jasnell ^?

@Fishrock123

This comment has been minimized.

Member

Fishrock123 commented Oct 22, 2015

I doubt it will actually have a negative effect on programs that use the repl, maybe only on tests.

@jasnell

This comment has been minimized.

Member

jasnell commented Oct 22, 2015

That one is going to be difficult to smoke test I think :-/ ... If we can identify some set of modules that could be affected, that would be easiest.

@evanlucas

This comment has been minimized.

Member

evanlucas commented Oct 23, 2015

I'd like to add #3485 if possible. Fixes the throw in fs.readFile if the buffer is too large.

@evanlucas

This comment has been minimized.

Member

evanlucas commented Nov 9, 2015

Since v5.0.0 has been released, any reason for this to stay open?

@Fishrock123 Fishrock123 closed this Nov 9, 2015

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