First io.js release build plan / discussion

[rvagg]

Things we need to make a first official io.js release in mid January (this is top of my head, please contribute if you see something that I don't have).

Target

At a minimum we need to release a solid source tarball that's tested, tagged and good to compile and use as a fully compatible version of joyent/node, v0.12-worthy. Version will be 1.0.0, perhaps with an -alpha.x suffix, that'll be up to the TC.

Binaries would be good but may be practical only for Linux at this stage in lieu of signing keys.

Need

• OSX 10.10 and 10.9 hooked up to CI (Voxer has machines ready for us to hook up, we just need to do some VM work) - @ryanstevens is responsible for this, @rvagg to work with him to make this happen
• CentOS5 hooked up to CI to ensure RHEL5-level compatibility (yak shaving abounds here) - @rvagg responsible for this, I believe I have a good strategy after shaving the RHEL6 yak with C++11

Nice but not essential

• OSX 10.8 hooked up to CI
• At least one version of FreeBSD hooked up to CI (Voxer has the hardware on offer for this)
• A Solaris-ish machine hooked up to CI, what are the chances of Joyent offering a box?
• Signing keys for io.js org so we can release proper Mac and Windows binaries
• Linux releases via deb.nodesource.com and rpm.nodesource.com (or similar hosts if not the same hosts) - @rvagg to work with @chrislea to make this happen

Decisions

• Do we mark Linux packages as "conflicting" with "nodejs" or set up an "alternatives" style system? (I know it's doable on Debian-based systems but am vague on RHEL/Fedora-based systems here)
• Exact version, up to TC, not an urgent decision
• How are tarballs named and hosted, straight from GitHub?

[yorkie]

How about after someone had ran make test, the test runtime will send back the result and testing machine information to our build system, it will help us collect more unexpected failure cases as possible, I'm unsure this is the right place to post this, just figure this out after reading @rvagg's article, thanks.

[rvagg]

@yorkie, check out https://jenkins-node-forward.nodesource.com and drill down in to "Console Output", it's all there. We still have a failure on ARM and intermittent failures on others, those need to be cleaned up so feel free to dig around in https://jenkins-node-forward.nodesource.com/job/iojs+v0.12+multi/ if you want to contribute to making the test suite more solid.

[yorkie]

Okay, thanks for the detailed guidance for me, i'm busy recently but i'm always interested in the build project for node(or iojs, haha), i will do check given links by you and wanna contribute to this upcoming project once i'm free, 🍒

[bnoordhuis]

Do we mark Linux packages as "conflicting" with "nodejs" or set up an "alternatives" style system? (I know it's doable on Debian-based systems but am vague on RHEL/Fedora-based systems here)

You can put a Conflicts: nodejs header in the .spec file. There's an additional safeguard in that rpm/yum won't let you install a package that overwrites files from an installed package (unless you force it to, of course.)

[bnoordhuis]

How are tarballs named and hosted, straight from GitHub?

Good question. I would suggest mirroring what nodejs.org currently does and host them at a stable and predictable URL, like http://iojs.org/dist/v1.2.3/iojs-v1.2.3.tar.gz, but that would require checking in the tarballs because iojs.org is currently a GH pages website.

[davidbanham]

dist.iojs.org/etc then?

It would make sense to keep big binary assets like that separate from the
website content.
On 5 Dec 2014 08:22, "Ben Noordhuis" notifications@github.com wrote:

How are tarballs named and hosted, straight from GitHub?

Good question. I would suggest mirroring what nodejs.org currently does
and host them at a stable and predictable URL, like
http://iojs.org/dist/v1.2.3/iojs-v1.2.3.tar.gz, but that would require
checking in the tarballs because iojs.org is currently a GH pages website.

—
Reply to this email directly or view it on GitHub
#18 (comment).

[indexzero]

👍 to dist.iojs.org as a separate repo backed by Github pages

[davidbanham]

Agree. Back it with github early on and we've always got the flexibility to
switch it out to S3+CloudFlare or similar later on.
On 5 Dec 2014 08:45, "Charlie Robbins" notifications@github.com wrote:

[image: 👍] to dist.iojs.org as a separate repo backed by Github pages

—
Reply to this email directly or view it on GitHub
#18 (comment).

[ghostbar]

@rvagg @chrislea I can help on the Debian releases, making up a reprepro on deb and helping on the infrastructure for it. Plus, I could be pushing the debian packages to the debian archive (I'm a debian developer)

[chrislea]

@ghostbar Thanks for the offer! We already have a build box with reprepro set up that we're using. And I don't think we're allowed to push the packages as they are into the real Debian archive because we statically link in basically everything (v8, cares, etc), which as I understand it is against the Debian packaging guidelines. But, if I'm wrong then I'm sure @rvagg and others would be interested in talking about official Debian support. So if that's the case please let us know.

[ghostbar]

@chrislea Ok yes, that's against the rules for getting into the archive and I understand the reasoning behind this as in: just download one .deb, install it and you're done.

Anyway, if it's going into a reprepro anyway, I don't see why we couldn't even make the separate v8 packages without adding too much issues into it. We could use the base as of how it's handled currently the v8 and nodejs packages on debian.

Let me know and I could work on it next weekend.

[stryju]

Hey guys!

Any progress re: Debian packages?

[chrislea]

We are working on them. Support for the current Debian stable (wheezy) is a godawful PITA because the compiler it ships with is too old to build iojs. And backporting a newer compiler brings its own headaches. So once we have that planned / sorted out we'll get packages built.