Moving repos / convergence #2327
Description
At this stage, the v3.x branch should be assumed to be the last release branch for io.js, what's on master will become Node.js v4.x and beyond along with convergence work which is largely contained within pull requests to nodejs/node—there are some additional changes but they are already coming over to this repo as pull requests, such as #2302.
With regard to releases & CI we have near-convergence but it's not complete:
- You can now test pull requests with the single Jenkins across io.js and joyent/node (and nodejs/node if we need it). Landing pull requests via Jenkins is still a work in progress. @orangemocha may want to fill in details of the exact status of this since he's done most of the work.
- Releases are completely separate processes for io.js and joyent/node. @misterdjules has documented the joyent/node process here, I have similar documentation here, but we haven't made progress on convergence of this because it also depends on nodejs.org being the release target and we're probably going to cherry-pick the best of both worlds for a convergence release process. We also need new signing keys, I've started that process but it turns out that getting money out of the Foundation is a non-trivial process! We'll be discussing release processes in @nodejs/build to make progress ASAP.
So, how do we handle this? How do we deal with the multiple repositories and how do we get towards a Node.js v4 alpha ASAP?
Proposed plan
I propose that we do the following as soon as we get consensus, it can go on tc-agenda if necessary.
Rename nodejs/io.js to nodejs/node
I've had discussions with many people about the merits of renaming vs just jumping over to nodejs/node. One of the interesting benefits of not renaming is that it resets the expectations of the entire contributor base (tsc, collaborators and beyond) that this is a new thing we are doing, not just io.js.
However, the current nodejs/node doesn't contain much that we can't afford to lose even if we were to delete it. There are pull requests in there that bring us to the convergence but the codebase is just io.js. So we could easily bring those pull reuqests into this repo and rename it and we keep the history and existing issues and pull requests that are more relevant to the converged codebase than those in joyent/node.
Already, pull requests and issues that are not directly relevant to 0.10 and 0.12 are being prompted to file against io.js, that can continue but with people being pointed to nodejs/node.
Create all future releases from nodejs/node
Not only for v4 but also v3 and even 0.10 and 0.12. This means the release tooling just needs to work in one way with the only difference being that v3 releases go to iojs.org but that'll end soon enough. I'm suggesting we have v0.10.x and v0.12.x branches for this to match the v3.x branch we now have.
Leave joyent/node in place for now
It'd be great if it could be moved to nodejs/node-legacy or similar but there's no reason that this should be a priority and existing tooling that points to joyent/node—not just official stuff but community tooling too, and while the GitHub web interface redirects, the GitHub API doesn't.
We should encourage all new issues against joyent/node to be filed in nodejs/node instead. We should encourage people who filed the existing pull requests over there to file them against nodejs/node and then work (slowly) to close all of them out completely.
Document the branch strategy for casual contributors
While the core group of contributors might be starting to get their heads around the new model that we've been discussing, it's vitally important that we communicate a simplified version of this that we can put at the top of CONTRIBUTING.md and (?) the top of README.md. Something simple enough that people are likely to read it but informational enough that it tells people which branch any pull requests should go against. Something like:
Issues should state clearly which version of Node.js or io.js they are reporting against
Pull requests should be made against master except where they are addressing bugs in older versions where the bugs either don't exist in master or do exist in master but the changes are significantly different and will therefore require a fresh pull request.
Stable releases are made from their own branches, with changes in master being cherry-picked from there into those branches where appropriate. Generally it should be left for the collaborator team to decide whether changes should be cherry-picked at all and to which branches.
The process for cherry-picking from master to stable branches will be interesting and we're going to learn best practices over time, I suspect that we'll see a lot of compounding pull requests where a cherry-pick isn't clean and requires some editing.
/cc @nodejs/tsc