Deciding what goes into LTS Releases vs. What Doesn't

[jasnell]

One of the more difficult decisions and differences between the two projects lies in the question what goes in to an LTS release vs. what doesn't. This currently is not addressed in the draft dev-policy.

It hinges on a very specific question: When an LTS Release is cut, is it simply a snapshot of the current development stream at a specific point in time or is it a targeted set of features/capabilities. The answer to this determines whether the project will work from a single stream (master with snapshots) or multiple streams (e.g. a dev master + stable master). With the latter approach, the LTS WG would decide which commits to cherry pick from the dev stream based on what it feels is "mature" or "complete".

The current dev-policy draft assumes a single stream with snapshots largely because that's where the document started. Is that the right approach for LTS releases moving forward?

[jasnell]

I've added a statement that says the LTS WG is required to maintain and publish a forward looking Roadmap for LTS releases.

[mhdawson]

I'm thinking that the only practical way is a full snapshot of master when the LTS is cut. The amount of work to pull specific features over, particular if only a subset is pulled over each time will be significant and increase as over time as the delta becomes larger.

[jasnell]

Yep. This makes the Development Branches critical for developing and incubating new ideas then moving those into master as complete thoughts. Whatever makes it successfully into master by the time the rc.1 is cut makes it into the LTS release.