Major version bump

[chrisdickinson]

By now we've gathered a sizeable number of PRs liable to require a major version bump. I've listed them below:

subsystem	issue title	issue links
process,lib	fix process.send() sync i/o regression	#760 #774
url	significantly improve the performance of the url module	#933
url	re-add path in url.format	#893
util	fixed behavior of isObject()	#822
os	remove trailing slash from os.tmpdir()	#747
freelist	Remove Ryan's Freelist feature	#569
deps	Moving to V8 4.{1,2}, reverting floating V8 patch*	#1026 #952

*: I might have noted this one incorrectly! Please let me know if this is in error.

I echo @domenic's sentiment here: I'd like to keep the number of breaking changes per major bump few in number, so this seems like a fairly good set of issues.

---

Our current setup for major bumps:

• Cut a new branch – v2.x.
• Bump the appropriate node_version.h version. Commit as "Starting work on v2.x".
• Merge the PRs constituting the major bump to v2.x.
• Switch the Github primary branch to v2.x.
• We may have to update Jenkins? @rvagg would you know more about this?

As a side effect of this:

• All existing PRs will be targeting the wrong branch (v1.x), including the PRs we would merge into the new v2.0.0 release.
• We also will have to decide on a course of action for supporting v1.x – that is, do we go the joyent/node approach and land PRs in the "oldest applicable" branch and forward port, or land in the current development version and backport? (I am in favor of the latter, but want to present both options.)
• Finally, the path we choose going forward with branch names & landing patches will influence our options for LTS support: if we keep vN.x branches, we are able to backport semver-minor changes to old versions, if we keep vN.N.x branches, we are only able to backport semver-patch changes.

A proposal:

Short-term: Do not cut major branches until we bump. Skip cutting the v1.x this one time, since it already exists. Develop current major version off of the master branch. Only cut vN.x branches at bump time. The downside is that all PRs will be mistargeted, but I don't think there's any avoiding that now. Land all changes in current development version, backporting them as necessary to older major lines. We keep vN.x, but commit to only backporting minor level patches sparingly; as an insurance policy for situations that warrant bringing a more secure API back to an old version. Generally only patches will be backported.

Long-term: I'd like to see the node_version.h fields templatized, so that the build system can grow a "release" job that can stamp the numbers in without having to affect git history. Currently that information is duplicated from the repository tags into the working tree, and I think it would ultimately be cleaner/easier to tool if it were purely repository metadata.

Thoughts on this, @iojs/tc, @iojs/build?

[tellnes]

The only way to let all existing prs target the correct branch is to continue develop on the v1.x branch. I don't think we want to do that. So +1 on moving development to the master branch.

Also +1 on creating vN.x branches and cutting LTS releases from that. If we in the future want to cut a LTS release for a older minor version where there exists a newer minor version in that major line, we can just create a vN.N.x branch for that particular case.

[mikeal]

+1 on master being current and cutting .x branches after major releases.

[trevnorris]

+1 letting master be the latest major version, and only branch when it's going into maintenance.

[indutny]

+1 for master.

[Fishrock123]

If we are removing freelist, can't we also remove sys?

[retrohacker]

👍 for master

In my head, LTS means a feature freeze with a focus on maintenance to reduce the chance of merging changes that introduce new bugs. Are there any huge risks in only allowing symver-patch changes in?

[brendanashworth]

+1 for master and splitting branches at bump time. @Fishrock123 I still think a lot of modules depend on it, but one of the issues with the sys deprecation is that most of the functions it would then call is also deprecated in util, too, so it mostly makes sense to remove them too - and then we realize we just broke a bunch of code because we removed "easily-maintainable deprecation notices", as someone put it.

edit: when we split new branches, can we add a change to the README saying that it is a legacy branch? that way less people get confused.

[qfox]

👍 for master.

[benjamingr]

👍 for master, it sounds reasonable.

[silverwind]

Adding the possible deprecation of the sync methods setServers and getServers in favor of an option on the async resolve here. Not sure yet how feasible it is to have it work async, so it's a bit of a unclear situation.

Related: #1071 and #894 (current crash bug)

[sam-github]

Why merge major PRs at all? Leave them tagged semver-major and accepted (or something), and don't merge them until TC decides that its time to bump. Then branch a maintenance version of the last major, bump the version on master, merge all the pending accepted major PRs, and keep on going forward.

It's not at all clear to me why io.js is currently on v1.x branch and not master. I assume it is some accident of history, probably that master was supposed to be like something in joyent/node, but having an unused master seems odd at this point.

@chrisdickinson IMO, #956 is also semver-major.