Repository navigation
Major version bump #1061
Description
Activity
The only way to let all existing prs target the correct branch is to continue develop on the
v1.xbranch. I don't think we want to do that. So +1 on moving development to themasterbranch.Also +1 on creating
vN.xbranches 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 avN.N.xbranch for that particular case.+1 on
masterbeing current and cutting .x branches after major releases.+1 letting master be the latest major version, and only branch when it's going into maintenance.
+1 for master.
If we are removing
freelist, can't we also removesys?👍 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?
+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
sysdeprecation is that most of the functions it would then call is also deprecated inutil, 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.
👍 for master.
👍 for master, it sounds reasonable.
Why merge major PRs at all? Leave them tagged
semver-majorandaccepted(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.
Please disregard my previous comment about the
dns.setServersdeprecation. After further consideration, I think it's not worth the trouble to deprecate an actively used API for a minor issue that could probably solved in userspace (once #894 is done).@sam-github leaving them in PRs is a free ticket to hell. Maintaining external PRs will certainly be a nightmare.
13 remaining items
@sam-github Just imagine how to merge a PR that was developed by somebody a 2-3 months (or 2 years) ago. It's a free ticket for sure, but still not a ride. It's a risk that can be reduced by merging these PRs to some branch.
@zxqfox nothing is perfect. And I'm not opposed to merging major PRs to a next-major branch, or something.
But I don't agree that merge conflicts on PRs must be the responsibility of io.js collabs.
Its normally the responsibility of the proposer of the PR to keep them in a state they can merge clean.
Especially if PR proposers knew that every 3 months major PRs would get pulled in. And they knew when that would be. And they clearly know their PR is semver-major... well, its going to be their responsibility to rebase their PR so it can merge clean.
What is your suggestion for this? Merge major PRs as they come, bump the major on master, and go for it? Or do you have some other proposal for slowing down the rate of release of MAJOR versions of io.js?
I'm in the "integers are cheap" camp: if we're going to do semver, this is what semver entails. What we're doing right now, and what most proposals seem to suggest doing, is cooking the books a bit. We do so at present by letting major changes idle in PRs. If we switch to a canary branch, we cook the books by merging major changes to a separate major branch. Either way, the end result is that we defer the work of fixing merge conflicts until some later time. I'd rather not get to the point where merges happen >1 month after the change. Fixing merge conflicts is some of the hardest work to get right – and it only gets more difficult the longer it's put off.
That said, this bears more thought. What we're trying to get to is a world where we have the upsides of the even/odd release model, without its downsides. The upside to that model was the natural "canary" set of releases – the odd version line – for any stable release, where users would stick to the stable release.
I'm +1 on anything that retains, or introduces friction on bumping major. Remember the guiding philosophy of Node that remains one of the main reasons we are all still here: small core, vibrant userland.
Core shouldn't be innovating faster than userland, we should be paving cowpaths. If we free ourselves up to move faster on breaking changes and major new features then we'll end up in the land of suck that we get from browser vendors (think fetch() and even the new streams API) and to some degree TC39 which is still somewhat disconnected from those on the ground.
Our job is not to make the awesome happen, it's to facilitate awesome happening outside of core--likely by people other than ourselves! Think about that next time someone proposes a major new feature, or you find yourself tempted to introduce something new.
I'm +1 on anything that retains, or introduces friction on bumping major. Remember the guiding philosophy of Node that remains one of the main reasons we are all still here: small core, vibrant userland.
I agree 100% with the sentiment that core should remain small and focused, and that the primary value of io.js is in the userland ecosystem.
However, the value of the major version number does not affect the size of core. Major version bumps are likely to smooth a rough edge in an API, fix inconsistent behavior, or upgrade transitive dependencies (like V8.) These are things that may cause a user to have to change their code, but it is by no means guaranteed – io.js is essentially a grab-bag module after all.
Minor version bumps, on the other hand, represent strictly new code. If we want to keep a small core, we should be introducing friction for minor version bumps. Major bumps are "platform and codebase health" changes, not a vetting ground for net new features.
I agree with @chrisdickinson on this one. I'm all for having more major version bumps if the list of changes looks like the one we have now (all small improvements but because they are minor changes in behavior we have to bump major).
I don't think that causing friction in doing a major release does anything other than increase the breakage they cause in userland and curb their adoption by the ecosystem. We have plenty of evidence this is the case by looking back on prior major releases of node.js, the longer the release took the longer it took for it to be adopted and the more things it broke.
That said, I think that bumping major any more often than Chrome does is going to be confusing and kinda scary for users :)
@chrisdickinson pointed out that if there is a canary branch, then non-semver-major commits must be merged onto it, and that means manual work and no nightly releases for canary
@indutny pointed out that leaving pull semver-major pull requests to get stale and require manual merging is not exactly optimal either.
And everyone agrees that merging every single major pull request as if it were any other pull request => the
XinX.Y.Zwill explodeThere's one common thread here - all of the above ideas imply that when there is a semver-major change, it should be described in code and submitted as a pull request. But what if semver-major changes were simply described in issues with a
semver-majortag? Once enough issues with that tag have accumulated, you comment on all of them saying that pull requests are being accepted. At that point, everyone can make pull requests (aimed at master) and they can be accepted just like all other pull requests, and once all of the semver-major issues have pull requests which have been merged into master, then you cut the release and increment theXinX.Y.ZThis is the only way to avoid all manual merging IMO. And I'm pretty sure everyone agrees that relying on manual merging (which is susceptible to human error) is a very bad thing.
For now @bnoordhuis has volunteered (thanks!) to cut a "next" branch and start merging majors into it, while merging minors and patches from v1.x to that branch.
when do we make the switch to
master?I'm pretty keen on moving way from
v1.xas well. Makes it so much easier to cut stable releases.The plan is to switch to master after the first v2.0.0 release.
Since we've got the ball rolling on this, I think we can close.
Discussion for 2.0.0 can continue in #1532
By now we've gathered a sizeable number of PRs liable to require a major version bump. I've listed them below:
4.{1,2}, reverting floating V8 patch**: 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:
v2.x.node_version.hversion. Commit as "Starting work on v2.x".v2.x.As a side effect of this:
v1.x), including the PRs we would merge into the newv2.0.0release.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.)vN.xbranches, we are able to backport semver-minor changes to old versions, if we keepvN.N.xbranches, 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.xbranches 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 keepvN.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.hfields 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?