search

nodejs / node

Node.js JavaScript runtime ✨🐢🚀✨
https://nodejs.org
Other
106.51k stars 29.03k forks source link

Release proposal: 1.8.0 #1436

Closed chrisdickinson closed 9 years ago

chrisdickinson commented 9 years ago

As it stands, there are some commits on master that are not part of v1.x, and some commits in v1.x that are not part of a v1.x release. To remedy this, and get us onto the master branch in anticipation of a v2.0.0 release, I propose a v1.8.0 release, the final non-support-related release in the v1.x line.

the proposed plan

actions

(eugh, accidentally overwritten by changelog!)

outcomes

The proposed changelog:

cc @iojs/tc @iojs/collaborators

jbergstroem commented 9 years ago

I'm very keen on landing #1429 beforehand. At least, part of it that fixes building against shared libraries.

One added action: switch default branch in jenkins job description.

rvagg commented 9 years ago

I like it

re release tooling - I don't think there's anything I need to do, there are some defaults but they are just defaults and shouldn't impact builds or tests.

re commit log, run changelog-maker --group to group them like we've been doing recently, it's easier to see the most impactful changes then.

re version, even though it's only the process.nextTick() changes that are forcing this, the bump in openssl fits nicely under there because of the potential for changes in user experience (even though in theory it shouldn't be noticable).

timing of this release is up to you but depending on the progress towards merging v8, we may see a 1.8.1 before we go 2.0.0 given the things that need to line up for that to be ready to go so perhaps we need a transitional git process that gives us the freedom to cut a 1.8.1 if 2.0.0 is taking longer than we expect? your call but keep that in mind.

yosuke-furukawa commented 9 years ago

I would like to land https://github.com/iojs/io.js/pull/1412/ . before v2.0.

rvagg commented 9 years ago

published changelog-maker v1.3.2 to account for that deps, build: commit

chrisdickinson commented 9 years ago

thanks for the changelog-maker tip!

re: timing and a potential 1.8.1: I was thinking about that a bit. I don't think the steps above would preclude us from making new releases on the v1.x line on the road up to v2.0.0 – at least, not for any technical reason. Patches comprising v1.8.1 would land in v1.x and be merged up to master. That said, I agree it'd be best to minimize the amount of time we're doing that for because past experience has shown that that can quickly get out of hand.

A note about the next branch, vs. what will become v2.0.0 per the above – at present, they have different merge-bases with v1.x. next is branched from v1.6.2, while v2.0.0 will end up being on top of the commits on master + the merge commit of v1.x. Once we've gone through the steps above, I propose we additionally:

  1. delete the existing next branch,
  2. re-cut next from master,
  3. cherry pick commits 41c00a2, 336dc08, and bb97b70 onto new next,
  4. land the v2.0.0 PRs (as applicable) onto next as applicable,
  5. and finally force push next to GitHub

That way when the nightly build kicks off we can treat that as the first release candidate for io.js v2.0.0.

Should we "fix" next sooner rather than later so that we can get an RC out earlier? Or should we approach re-cutting next differently (or not at all)? It seems to me one of the branches (out of next, v1.x, and master) will need to be rebased/force pushed, and next is probably the one that will cause the least stress.

The alternative is to drop the following commits from master and then fast-forward merging v1.x to master, but then next is still based off of v1.6.2 and we'll have dropped commits (albeit unused ones).

rvagg commented 9 years ago

I'm going to opt out of making suggestions on this one, if @bnoordhuis has time then he should provide input since he started the work on next. You have reminded me though that I'll need to change the nightly builds to stop checking the head of v1.x, that's one hard-wired area where branch names matter.

I think at this stage my vote would be for continuing to publish nightlies off v1.x even after 1.8.0 and only switch to building them off master when we are close. In the meantime I can switch next-nightly to master if we get that next -> master merge done and start working on 2.0.0 in master, then our RC builds can come out of there and we either tell people to just use the next-nightly builds and consider them RC or we can properly label a build or two "RC" in some way.

Fishrock123 commented 9 years ago
  1. Before we cut a working on-style commit, we merge v1.x into master using git checkout master; git merge -Xtheirs v1.x and issue a PR against master. I'll put up a WIP PR as an example of what that will look like so it can be pre-reviewed.

Not so sure about this. There's commits from the past that haven't been in a release between, which will just be confusing (even though they are mostly docs commits iirc).

I'd think it would make more sense to push over master and cherry-pick anything that isn't in the new master, as applicable.

bnoordhuis commented 9 years ago

I have to say, it all sounds rather complicated.

Next is essentially v1.x + V8 4.2 + semver-major patches. Master doesn't contain anything interesting. Why not force-push next:master (or if force-pushing sets off alarm bells: delete master and rename or branch from next) and merge v1.x into next/master after every release?

Fishrock123 commented 9 years ago

and merge v1.x into next/master after every release?

I think the plan is to backport patches only for LTS, and not do how node is currently doing it?

chrisdickinson commented 9 years ago

In any case, if we don't care about the commits master has that v1.x doesn't, dropping them is definitely an option and simplifies things a bit. Didn't want to assume we were on with dropping that data, though :)

I'll revise in a bit.

On Apr 16, 2015, at 10:45 AM, Jeremiah Senkpiel notifications@github.com wrote:

and merge v1.x into next/master after every release?

I think the plan is to backport patches only for LTS, and not do how node is currently doing it?

— Reply to this email directly or view it on GitHub.

bnoordhuis commented 9 years ago

I think the plan is to backport patches only for LTS, and not do how node is currently doing it?

Right, I forgot. That's fine then, no up-merges.

fengmk2 commented 9 years ago

How about land #1242 into 1.8.0?

Fishrock123 commented 9 years ago

In any case, if we don't care about the commits master has that v1.x doesn't, dropping them is definitely an option and simplifies things a bit. Didn't want to assume we were on with dropping that data, though :)

Not 100% sure of this. We should do a diff and check what v1.x is missing, then evaluate. :)

chrisdickinson commented 9 years ago

@fishrock123 those commits are linked above.

On Apr 16, 2015, at 11:07 AM, Jeremiah Senkpiel notifications@github.com wrote:

In any case, if we don't care about the commits master has that v1.x doesn't, dropping them is definitely an option and simplifies things a bit. Didn't want to assume we were on with dropping that data, though :)

Not 100% sure of this. We should do a diff and check what v1.x is missing, then evaluate. :)

— Reply to this email directly or view it on GitHub.

Fishrock123 commented 9 years ago

I think the contribution policy stuff all exists in better form in v1.x today. (That is: e7dec60, cafac11, 7ee5c4e, 8c60aaa, 051dc54, & f60abb0) /cc @mikeal though.

We already have the TC meetings in v1.x (2c7847b & 3cb5f3d)

That leaves 3 commits (excluding merges and the 0.13.0 version bump):

The last one appears to have landed in v1.x at cca8de6. (No PR metadata, couldn't find it. EDIT: #834)

That leaves just these two:

Shall I open a PR to get these into v1.x?

Edit: the stream change is easy. the vcbuild.bat change has some conflicts, not too bad though.

cjihrig commented 9 years ago

I ported that in cca8de6709ece5b4791d52a8b834da83bfb782d5

cjihrig commented 9 years ago

Sorry for the lack of metadata. It was in a batch of commits I cherry picked over from joyent/node.

Fishrock123 commented 9 years ago

Ah, found it, was from #834

See #1444 for a cherry-pick of the last two.

chrisdickinson commented 9 years ago

Okay, we're going to reset master to 3a9754a27, that way v1.x can fast-forward merge onto it.

silverwind commented 9 years ago

Are we in a semver-minor window right now? I'd like to land #1363, which is strictly speaking a bugfix and a deprecation in one.

chrisdickinson commented 9 years ago

Re: next: rubber-ducked my way through it in IRC a bit. Here's my thoughts:

During the steady state, next contains the necessary commits to merge the next v8 version and "Merge tag vN-1.X.X" commits bringing in the commits on master. Additionally, it may contain accepted semver-major level changes.

During the run up state, master is now set up to release the next major version. Only the next v8 version commits are brought into master at that point. next is (briefly) vestigial at this point. Once we have a new v8 version to start landing (or other accepted semver-major commits), we re-cut next, based off of the starting on vN-1.X.X commit.

chrisdickinson commented 9 years ago

@silverwind Yep, that sounds good to me, especially since we're coming up on semver-major so we can remove the hack :)

chrisdickinson commented 9 years ago

Ok, assuming there are no issues raised, I'll plan on cutting this release tomorrow (4/17) in the late AM, PST.

1363, #1444, #1242 will go in, assuming they land before then. #1412 might be a good candidate to land on master after the merge, as @Fishrock123 noted in that PR.

Fishrock123 commented 9 years ago

I will also attempt to make a doc-deprecation PR for util.is* real soon, we'll see.

othiym23 commented 9 years ago

Just putting down a marker here that I would very much like if npm@2.8.3, which will be npm@latest by this evening, is incorporated into 1.8.0, because it has much better git repo handling than npm@2.7.6.

Fishrock123 commented 9 years ago

@othiym23 sure, I'm around to do a review if your PR it. :)

shigeki commented 9 years ago

Here I wrote a note about a crypto performance for OpenSSL-1.0.2a on iojs v1.8.0. https://github.com/iojs/io.js/wiki/Crypto-Performance-Notes-for-OpenSSL-1.0.2a-on-iojs-v1.8.0

Owing to AVX2 support, the benchmark shows that iojs-v1.8.0 has achieved about 140% - 160% performance gain on Haswell for RSA, SHA256 and AES-GCM operations compared with v1.7.1.

iojs_crypto_bench

othiym23 commented 9 years ago

npm upgrade to npm@2.8.3 is in #1448 and awaiting review.

rvagg commented 9 years ago

/cc @iojs/evangelism see notes above about crypto perf in 1.8.0.

yosuke-furukawa commented 9 years ago

@rvagg yes. listed here. https://github.com/iojs/evangelism/issues/55#issuecomment-93962703

jbergstroem commented 9 years ago

I pulled the most important part out of #1429 to a new PR which should be simpler to review/land: #1450. I suggest they change seats in the 1.8.0 release milestone.

chrisdickinson commented 9 years ago

Hey all - I'll be starting the process in about 45 minutes. Sorry for the delay / thanks for your patience!

On Apr 17, 2015, at 5:24 AM, Johan Bergström notifications@github.com wrote:

I pulled the most important part out of #1429 to a new PR which should be simpler to review/land: #1440. I suggest we replace it in the 1.8.0 release milestone.

— Reply to this email directly or view it on GitHub.

Fishrock123 commented 9 years ago

Looks like #1450 isn't perfect, but we should at least apply this to fix shared library building: #1434

diff --git a/configure b/configure
index 19ec28f..8a19a53 100755
--- a/configure
+++ b/configure
@@ -658,7 +658,7 @@ def configure_node(o):
 def configure_libz(o):
   o['variables']['node_shared_zlib'] = b(options.shared_zlib)

-  if b(options.shared_zlib) == True:
+  if options.shared_zlib:
     o['libraries'] += ['-l%s' % options.shared_zlib_libname]
   if options.shared_zlib_libpath:
     o['libraries'] += ['-L%s' % options.shared_zlib_libpath]
@@ -668,8 +668,8 @@ def configure_libz(o):

 def configure_http_parser(o):
     o['variables']['node_shared_http_parser'] = b(options.shared_http_parser)
-    
-    if b(options.shared_http_parser) == True:
+
+    if options.shared_http_parser:
       o['libraries'] += ['-l%s' % options.shared_http_parser_libname]
     if options.shared_http_parser_libpath:
         o['libraries'] += ['-L%s' % options.shared_http_parser_libpath]
@@ -680,7 +680,7 @@ def configure_http_parser(o):
 def configure_libuv(o):
   o['variables']['node_shared_libuv'] = b(options.shared_libuv)

-  if b(options.shared_libuv) == True:
+  if options.shared_libuv:
     o['libraries'] += ['-l%s' % options.shared_libuv_libname]
   if options.shared_libuv_libpath:
     o['libraries'] += ['-L%s' % options.shared_libuv_libpath]
chrisdickinson commented 9 years ago

An update: it looks like the npm PR introduced a bit of OSX fs case-sensitivity weirdness, so @fishrock123 and I (and Arnavion) are working through it on IRC.

chrisdickinson commented 9 years ago

Cool. Anyone want to help me with the CHANGELOG? In particular, are there any known issues I should add? Here's what I have so far re: notable changes:

Notable changes

Known issues

Fishrock123 commented 9 years ago

Notable Issues should be based on https://github.com/iojs/io.js/commit/f3e9da3e69393acb6f2cb90c4dc53ae5908ac9ef since it was forgotten last time.

other possibilities: https://github.com/iojs/io.js/issues/1435 / https://github.com/iojs/io.js/issues/1403 (Edit: both of these have existed since forever.)

I wouldn't put any of the v8 bugs here, mostly because they are things less in our control.

Fishrock123 commented 9 years ago

Note that this was fixed in 1.7.0:

silverwind commented 9 years ago

That readline bug #1403 has been there for as long as I can remember. If we want to be meticulous about it, we could add it, but I think it's probably not worth to add a note for it.

Fishrock123 commented 9 years ago 
* **npm**: Upgrade npm to 2.8.3. See the [release notes](https://github.com/npm/npm/releases/tag/v2.8.3) for details. Includes improved git support. Summary:
  * [`387f889`](https://github.com/npm/npm/commit/387f889c0e8fb617d9cc9a42ed0a3ec49424ab5d)
  [#7961](https://github.com/npm/npm/issues/7961) Ensure that hosted git SSH
  URLs always have a valid protocol when stored in `resolved` fields in
  `npm-shrinkwrap.json`. ([@othiym23](https://github.com/othiym23))
  * [`394c2f5`](https://github.com/npm/npm/commit/394c2f5a1227232c0baf42fbba1402aafe0d6ffb)
  Switch the order in which hosted Git providers are checked to `git:`,
  `git+https:`, then `git+ssh:` (from `git:`, `git+ssh:`, then `git+https:`) in
  an effort to go from most to least likely to succeed, to make for less
  confusing error message. ([@othiym23](https://github.com/othiym23))
  * [`431c3bf`](https://github.com/npm/npm/commit/431c3bf6cdec50f9f0c735f478cb2f3f337d3313)
  [#7699](https://github.com/npm/npm/issues/7699) `npm-registry-client@6.3.2`:
  Don't send body with HTTP GET requests when logging in.
  ([@smikes](https://github.com/smikes))
  * [`15efe12`](https://github.com/npm/npm/commit/15efe124753257728a0ddc64074fa5a4b9c2eb30)
  [#7872](https://github.com/npm/npm/issues/7872) Use the new version of
  `hosted-git-info` to pass along credentials embedded in git URLs. Test it.
  Test it a lot. ([@othiym23](https://github.com/othiym23))
  * [`b027319`](https://github.com/npm/npm/commit/b0273190c71eba14395ddfdd1d9f7ba625297523)
  [#7920](https://github.com/npm/npm/issues/7920) Scoped packages with
  `peerDependencies` were installing the `peerDependencies` into the wrong
  directory. ([@ewie](https://github.com/ewie))
  * [`6b0f588`](https://github.com/npm/npm/commit/6b0f58877f37df9904490ffbaaad33862bd36dce)
  [#7867](https://github.com/npm/npm/issues/7867) Use git shorthand and git
  URLs as presented by user. Support new `hosted-git-info` shortcut syntax.
  Save shorthand in `package.json`. Try cloning via `git:`, `git+ssh:`, and
  `git+https:`, in that order, when supported by the underlying hosting
  provider. ([@othiym23](https://github.com/othiym23))
chrisdickinson commented 9 years ago

Building nightlies now. – build is here.

silverwind commented 9 years ago

@Fishrock123 no need to post the markdown, collaborators can just hit 'edit' on your post to get it :wink:

Fishrock123 commented 9 years ago

Also notable:

The configure shared lib fix, require('.') "fix"

Possibly process.nextTick(cb, ...args), but I think we were maybe not publicizing that too much (edit: looks like this ones's there.)

Fishrock123 commented 9 years ago

win,build: make delay-load hook optional on Windows (Bert Belder)

That already existed.

chrisdickinson commented 9 years ago

Resetting master to 3a9754a27bf3b39fd4f83925fefdd3875b24b851.

silverwind commented 9 years ago

The require change should be noted. Here:

chrisdickinson commented 9 years ago

@Fishrock123 wisely suggested preserving the old master version in a branch – here it is, old-master.

chrisdickinson commented 9 years ago

Something untowards happened with the osx nightly, looks like it couldn't reach Github? Restarted here.

chrisdickinson commented 9 years ago

Preview of the changelog + commit (see top commit) is up.

chrisdickinson commented 9 years ago

Nightlies are still seeing some issues building. Going to ignore for now, since there's no installer changes.

chrisdickinson commented 9 years ago

io.js now defaults to master. Release build has started. v1.x branch is set up to work on v1.8.1. master is set up to work on v2.0.0.