chore(README): Update our branching strategy

[jayphelps]

As discussed in today's RxJS team meeting, we feel it would be more simple to use two branches instead of three.

• master - commits that will be included in the next minor or patch release
• next - commits that will be included in the next major release (breaking changes)

We need to make the actual branches for next still.

---

We haven't really thought through the name "next" much. It is ambiguous, since it is intended to mean "next major release" (right now 6.0) not "next release in general" (e.g. 5.0.2) We didn't want to name the branch the literal version number, e.g. 6.0 because it would mean switching branches for every major release--but perhaps that's not the end of the world. Alternative name suggestions welcome. Maybe just major ?

We may also find that this approach isn't ideal. For example, ember and react both consider the master branch to be the latest and greatest canary, which includes everything (except short-lived patches that are incompatible), including breaking changes for future major version bumps. They then maintain a separate branch for the current stable version, cherry-picking commits for minor/patch releases. This is basically the opposite of what we just decided to do (described in this PR) It's unclear which approach is best for us.

[coveralls]

Coverage remained the same at 97.674% when pulling 1612c4f on branching into dc06e01 on master.

[tetsuharuohzeki]

@jayphelps Do you have any plan to release this next branch as alpha build or nightly build?

[jayphelps]

@saneyuki not anything committed yet, but we're definitely considering it. The next branch won't likely change too often, since we won't have super frequent breaking changes. We're more interested in releasing a package version that is some form of canary--which would basically include anything we would include in the next release; usually that's just what is in master, but when we're nearing a major version bump, that will include things from next. We're not 100% set on the name next since it's ambiguous--it means "next major version release" not "next release in general".

[coveralls]

Coverage remained the same at 97.674% when pulling fbaa37c on branching into dc06e01 on master.

[tetsuharuohzeki]

@jayphelps

I see.

We're more interested in releasing a package version that is some form of canary--which would basically include anything we would include in the next release

How long are you planning to release major version? Is it on-demand-driven? or be still in considering?

[benlesh]

LGTM

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.