Skip to content
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

Release proposal: 1.8.0 #1436

Closed
chrisdickinson opened this issue Apr 16, 2015 · 97 comments
Closed

Release proposal: 1.8.0 #1436

chrisdickinson opened this issue Apr 16, 2015 · 97 comments
Labels
meta Issues and PRs related to the general management of the project.
Milestone

Comments

@chrisdickinson
Copy link
Contributor

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

@brendanashworth brendanashworth added the meta Issues and PRs related to the general management of the project. label Apr 16, 2015
@jbergstroem
Copy link
Member

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
Copy link
Member

rvagg commented Apr 16, 2015

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
Copy link
Member

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

@rvagg
Copy link
Member

rvagg commented Apr 16, 2015

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

@chrisdickinson
Copy link
Contributor Author

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
Copy link
Member

rvagg commented Apr 16, 2015

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
Copy link
Contributor

  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.

@Fishrock123 Fishrock123 added this to the 1.8.0 milestone Apr 16, 2015
@bnoordhuis
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor Author

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 [email protected] 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
Copy link
Member

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
Copy link
Contributor

fengmk2 commented Apr 16, 2015

How about land #1242 into 1.8.0?

@Fishrock123
Copy link
Contributor

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
Copy link
Contributor Author

@Fishrock123 those commits are linked above.

On Apr 16, 2015, at 11:07 AM, Jeremiah Senkpiel [email protected] 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
Copy link
Contributor

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

  • [cfcb1de] - stream: remove duplicated expression (@yorkie)
  • [9116fcd] - build: use %PYTHON% instead of python (@rvagg)
  • [25702ab] - net: remove use of arguments in Server constructor (@cjihrig)

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:

  • [cfcb1de] - stream: remove duplicated expression (@yorkie)
  • [9116fcd] - build: use %PYTHON% instead of python (@rvagg)

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
Copy link
Contributor

cjihrig commented Apr 16, 2015

  • [25702ab] - net: remove use of arguments in Server constructor (@cjihrig)

I ported that in cca8de6

@cjihrig
Copy link
Contributor

cjihrig commented Apr 16, 2015

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

@Fishrock123
Copy link
Contributor

Ah, found it, was from #834

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

@chrisdickinson
Copy link
Contributor Author

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

@silverwind
Copy link
Contributor

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
Copy link
Contributor Author

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

  • The state we've developed v1.x in is the "steady state" of the repository. That is, each release is expected to be followed by another release in the same major line (v1.0.0 -> v1.1.0 or v1.0.1, for example).
  • The state are in right now is the "run up state" of the repository. The next release is expected to be a major version.

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
Copy link
Contributor Author

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

@chrisdickinson
Copy link
Contributor Author

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
Copy link
Contributor

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

@othiym23
Copy link
Contributor

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

@Fishrock123
Copy link
Contributor

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

@shigeki
Copy link
Contributor

shigeki commented Apr 17, 2015

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

@indutny
Copy link
Member

indutny commented Apr 18, 2015

Aaah, really! That's great then! @chrisdickinson we are good

@indutny
Copy link
Member

indutny commented Apr 18, 2015

Thank you, @shigeki

@jbergstroem
Copy link
Member

Proper ABI versioning <3

@rvagg
Copy link
Member

rvagg commented Apr 18, 2015

OK, 1.8.1 it is then, no 1.8.0 release and the NODE_MODULE_VERSION rolled back so no ABI breakage. I'm +0 on removing the 1.8.0 tag--one benefit would be that you could write the changelog as if 1.8.0 didn't even exist.
I'll try and get OSX sorted out ASAP and keep you updated here.

@rvagg
Copy link
Member

rvagg commented Apr 18, 2015

(Edited comment, sorry email recipients)

@shigeki
Copy link
Contributor

shigeki commented Apr 18, 2015

Sorry to everyone for confusion. It was my job to notice ABI compatibilities before upgrading.

@Fishrock123
Copy link
Contributor

but in a way that does not break binary compatibility. This means that an application compiled and dynamically linked with 1.0.0 does not need to be recompiled when the shared library is updated to 1.0.2.

It says it shouldn't need to be recompiled?

Did we not need the ABI bump?

Honestly I still find it silly we can't do ABIs for minors. ¯_(ツ)_/¯

@chrisdickinson
Copy link
Contributor Author

@shigeki @indutny this is great news! I'll redo the v1.8.1 PR so that OpenSSL remains in. And no need to apologize – thanks again for your hard work!

@Fishrock123 We still have to revert the python env var change – cmd.exe treats its use in quotes at the bottom of vcbuild.bat as a string, not a command, and fails out due to that (as I understand it).

@rvagg I'll delete the v1.8.0 tag. Once OSX works (and the v1.8.1 PR is updated & approved) we can cut the release.

On Apr 18, 2015, at 7:25 AM, Jeremiah Senkpiel [email protected] wrote:

but in a way that does not break binary compatibility. This means that an application compiled and dynamically linked with 1.0.0 does not need to be recompiled when the shared library is updated to 1.0.2.

It says it shouldn't need to be recompiled?

Did we not need the ABI bump?

Honestly I still find it silly we can't do ABIs for minors. ¯_(ツ)_/¯


Reply to this email directly or view it on GitHub.

@chrisdickinson
Copy link
Contributor Author

v1.8.0 tag deleted, #1460 is updated and tests are running. Once OSX is back up (and the tests all pass) we should be good to go ahead with v1.8.1, after which I'll merge these commits into master.

@RnbWd
Copy link

RnbWd commented Apr 18, 2015

It looks like everything passed except for pi1! I'm just excited about this release feeling anxious waiting.

You're probably already aware of this, but it looks like the pi1 distro takes a really long to compile, orders of magnitude longer. Maybe the process would be more efficient separating the arm6 build? I have no idea how Jenkins works, but I own 3 raspi's and use iojs on them frequently :) Arm6 is a very special use case thou, I'd volunteer one of my pi's full time if that'd help at all?

I also have no idea what I'm talking about, so if something else is happening behind the scenes then nm

@rvagg
Copy link
Member

rvagg commented Apr 20, 2015

@chrisdickinson last nightly worked in all except for the windows machines: https://jenkins-iojs.nodesource.com/job/iojs+release+nightly/154/ -> https://iojs.org/download/nightly/v1.8.1-nightly2015042077db7e168e/

We need that Windows vcbuild.bat fix in so we can get a fully successful nightly done.

@chrisdickinson
Copy link
Contributor Author

Ok. Going ahead with iojs v1.8.1 release build.

(Sidenote: I think I might PR some "if this step goes wrong" bailout instructions into the releases doc.)

@chrisdickinson
Copy link
Contributor Author

Looks like windows is having trouble archiving the build artifact. However, the msi file is created and works. Edit: specifically, it's missing the .exe.

@chrisdickinson
Copy link
Contributor Author

Holding off on promoting and signing until we figure out what's going on with Windows.

@chrisdickinson
Copy link
Contributor Author

OSX, Windows x64 msi, and CentOS look good!

@chrisdickinson
Copy link
Contributor Author

Announced on twitter. Thanks everyone! I'll leave this issue open for 24 hours and close if there have been no problems since. Will also merge the v1.8.1 changes into master.

Starefossen pushed a commit to Starefossen/docker-iojs that referenced this issue Apr 21, 2015
PR-URL: nodejs#53
Related: nodejs/node#1436

Signed-off-by: Hans Kristian Flaatten <[email protected]>
mathiasbynens referenced this issue Apr 21, 2015
Notable Changes:

* build: Support for building io.js as a static
  library (Marat Abdullin) #1341
* deps: upgrade openssl to 1.0.2a (Shigeki Ohtsu) #1389
* npm: Upgrade npm to 2.8.3. (Forrest L Norvell) #1448
* src: allow multiple arguments to be passed to
  process.nextTick (Trevor Norris) #1077
* module: the interaction of require('.') with NODE_PATH has been
  restored and deprecated. This functionality will be removed at
  a later point. (Roman Reiss) #1363
@julianduque
Copy link
Contributor

This can be closed now, great job

@gopat
Copy link

gopat commented Apr 26, 2015

Sorry to be such a pita, but... ¿aren't the armv6 missing for 1.8.1?

PD: [OffTopic] Soon i will get my hands on a rpi2 and will probably stop whinning(noticing).

@Fishrock123
Copy link
Contributor

I think they weren't promoted yet. @chrisdickinson?

@gopat
Copy link

gopat commented Apr 27, 2015

So he is who's meant to promote 'em... well, i think he's got way more important tasks to worry about right now (#1506 for iojs v2.0.0), so this might very well wait 'till 2.0.0 gets out the oven IMHO.

Bonus: programmer_interrupted.png

Edited: not displaying image due to size -@Fishrock123

@chrisdickinson
Copy link
Contributor Author

Reopening until the armv6 build is out. I re-ran tools/release.sh, but there doesn't appear to be anything up there to promote. Should I re-run the entire release build, or is it possible to re-run a single build? This is the release job – most of red there is caused by a jenkins bug. cc'ing @rvagg for advice!

@rvagg
Copy link
Member

rvagg commented Apr 28, 2015

@chrisdickinson re-run the entire release build and ping me when you want to promote and I'll clean out everything but armv6

@rvagg
Copy link
Member

rvagg commented Apr 28, 2015

or re-run the release build and manually kill all of the non-armv6 builds in jenkins and you'll get the same effect without needing me

@chrisdickinson
Copy link
Contributor Author

OK! armv6 promoted, it should be good to go. Closing the issue now. Thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests