Release proposal: 1.8.0

[chrisdickinson]

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

• Master is the new development branch.
• There is no v2.x branch. It will be cut once a v3.0.0 release is made to prevent having to constantly update it to match master.
• All existing PRs will target the wrong branch. Or, more charitably, they'll target an older branch than they intended. I will make an effort to tag these PRs with a tag – targets-master might be best?
• We should follow up with commits to update the documentation and build tooling, if need be.
• Bug and security fixes should be the only PRs landed in the v1.x branch.

questions

• Should we wait for any other commits to make it into v1.x before switching to master / preparing for the v2.x release?
• @rvagg / @iojs/build – is there anything that needs to be done to the release tooling to account for the branch switch?

The proposed changelog:

• [431673ebd1] - buffer: fast-case for empty string in byteLength (Jackson Tian) #1441
• [91943a99d5] - build: use %PYTHON% instead of python (Rod Vagg) #1444
• [c7769d417b] - build: Expose xz compression level (Johan Bergström) #1428
• [a530b2baf1] - build: fix error message in configure (Shigeki Ohtsu) #1389
• [92dfb794f9] - build: enable ssl support on arm64 (Shigeki Ohtsu) #1389
• [7de0dcde83] - deps: make node-gyp work with io.js (cjihrig) #990
• [4870213f9e] - deps: upgrade npm to 2.8.3 (Forrest L Norvell)
• [49bb7ded2c] - deps: fix git case sensitivity issue in npm (Chris Dickinson) #1456
• [4830b4bce8] - deps: add docs to upgrade openssl (Shigeki Ohtsu) #1389
• [11bec72c87] - deps: update asm files for openssl-1.0.2a (Shigeki Ohtsu) #1389
• [53924d8ebe] - deps: update asm Makefile for openssl-1.0.2a (Shigeki Ohtsu) #1389
• [418e839456] - deps: update openssl.gyp/gypi for openssl-1.0.2a (Shigeki Ohtsu) #1389
• [02f12ab666] - deps: update opensslconf.h for 1.0.2a (Shigeki Ohtsu) #1389
• [eb7a23595f] - deps: add x32 and arm64 support for opensslconf.h (Shigeki Ohtsu) #1389
• [033a663127] - deps: replace all headers in openssl (Shigeki Ohtsu) #1389
• [ae8831f240] - deps: backport openssl patch of alt cert chains 1 (Shigeki Ohtsu) #1389
• [71316c46d9] - deps: fix asm build error of openssl in x86_win32 (Shigeki Ohtsu) #1389
• [d293a4f096] - deps: fix openssl assembly error on ia32 win32 (Fedor Indutny) #1389
• [e4872d7405] - deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389
• [a1c9ef3142] - deps, build: add support older assembler (Shigeki Ohtsu) #1389
• [76f219c128] - doc: Document forced pushing with git (Johan Bergström) #1420
• [12e51d56c1] - doc: add Addon API WG (Rod Vagg) #1226
• [7956a13dad] - http: logically respect maxSockets (fengmk2) #1242
• [5b844e140b] - module: fix style (Roman Reiss) #1453
• [3ad82c335d] - (SEMVER-MINOR) module: handle NODE_PATH in require('.') (Roman Reiss) #1363
• [cd60ff0328] - net: add fd into listen2 debug info (Jackson Tian) #1442
• [10e31ba56c] - (SEMVER-MINOR) node: allow multiple arguments passed to nextTick (Trevor Norris) #1077
• [116c54692a] - openssl: fix keypress requirement in apps on win32 (Shigeki Ohtsu) #1389
• [62f5f4cec9] - src: remove duplicate byteLength from Buffer (Jackson Tian) #1438
• [51d0808c90] - stream: remove duplicated expression (Yazhong Liu) #1444
• [deb9d23d7b] - test: fix error message check for openssl-1.0.2a (Shigeki Ohtsu) #1389
• [ca8c9ec2c8] - win,node-gyp: optionally allow node.exe/iojs.exe to be renamed (Bert Belder) #1266

cc @iojs/tc @iojs/collaborators

[jbergstroem]

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]

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]

I would like to land #1412 . before v2.0.

[rvagg]

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

[chrisdickinson]

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]

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]

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]

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]

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]

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]

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]

How about land #1242 into 1.8.0?

[Fishrock123]

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. :)