Updating with section about next branch releases.

[mikeal]

This is a minor update to include some notes that appear to be the consensus in nodejs/node#1997

The name of the channel and the versioning is still being discussed so it is not addressed.

[Fishrock123]

Stalling for reasons mentioned in nodejs/node#1997 & nodejs/node#2215 (comment)

[mikeal]

@Fishrock123 the language in the PR is pretty non-specific so I'm curious what "wouldn't work well with git?"

[trevnorris]

@mikeal Under the plan thus far there would need to be continual merges across branches. This renders bisecting issues much more difficult, and makes tracking down issues where two commits combine to have side effects exponentially so.

It creates tree commit conflicts if the same patch needs to be landed on multiple merged branches prior to a merge. So at some point in time the same change will have essentially happened twice.

If a migration period is allowed, which personally I believe it should, then maintaining multiple major releases for a short period of time becomes more awkward. The last commit from stable major must be branched regardless of LTS so it has a brief period of time it can overlap with master. While no new features would need to be released on that branch, any security patches should.

[mikeal]

@trevnorris I wrote this up before I listened to the LTS WG call that detailed your cherry-pick plan. I talked with @rvagg about that yesterday and a few reservation I had, but with a slight modification I think that we can resolve those without a significant change to what you're proposing. Rod is going to write up a new plan and we can shelve this PR until that is up and resolved.

[trevnorris]

@mikeal Okay. I was just responding to you question to @Fishrock123. (for posterity and whatnot)