Meeting: Release plan bikeshed

[rvagg]

Building on discussions in many previous issues, the status of which is best summarised in #2215, we're trying to get to some closure here, particularly to also get alignment with the LTS plan.

In this week's LTS meeting and today's (yesterday's?) TSC meeting, we're starting to get a stronger consensus around a model that has been outlined by @trevnorris about how we use branches and master in particular. Most of us simply have fatigue over this and just want to land on something practical.

Remaining details that are still in flux are mostly around how to deal with ongoing V8 upgrades in master and other breaking changes and how this impacts canary/next/whatever builds and people relying on them and mostly how that impacts on contributors coming to the project not familiar with how we have it set up. Another topic for discussion is the process by which those changes are propagated around to other branches. Do we have a strict policy of landing all changes on master that fit there or can we be more flexible about where things land and then cherry-pick? Do we have any use for merges with this plan or is it all cherry-picking? (I'd ask about rebasing but I fear the reaction to that). And what mechanisms can we employ, human and technological, to ensure that changes propagate where they should and important commits don't get lost in the master firehose.

SO, with that, I'm proposing yet another meeting, a separate one, for those interested in trying to hash out enough of the details that we can present a plan that's complete enough to be able to vote on.

Because I really don't want another 6am I'm using 1 hour later than our regular slot, ~1 day 7 hours the time of this post.

9:00 PM Friday, 24 July 2015 UTC: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Release%20plan%20bikeshed+2015-07-24&iso=20150724T21

Hangout on Air for participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYdv26U8GY0wS7lCe9wMCCORdt4c7-QzcKxnko5q80UDKfK51Q

YouTube feed for lurkers and watching later: http://www.youtube.com/watch?v=JwwTZIRUoHA

This is not restricted to the TSC if you think you can make a valuable contribution to this; just be aware that (a) we have a limit on the number of people that can join the HOA and (b) some of us are sick of endless discussion about this topic.

Pinging @nodejs/tsc, and particularly @trevnorris, @jasnell, @mikeal, @chrisdickinson, I hope y'all can make it.

[jasnell]

+1. Will be there
On Jul 23, 2015 6:59 AM, "Rod Vagg" notifications@github.com wrote:

Building on discussions in many previous issues, the status of which is
best summarised in #2215 #2215,
we're trying to get to some closure here, particularly to also get
alignment with the LTS plan.

In this week's LTS meeting and today's (yesterday's?) TSC meeting, we're
starting to get a stronger consensus around a model that has been outlined
by @trevnorris https://github.com/trevnorris about how we use branches
and master in particular. Most of us simply have fatigue over this and
just want to land on something practical.

Remaining details that are still in flux are mostly around how to deal
with ongoing V8 upgrades in master and other breaking changes and how
this impacts canary/next/whatever builds and people relying on them and
mostly how that impacts on contributors coming to the project not familiar
with how we have it set up. Another topic for discussion is the process by
which those changes are propagated around to other branches. Do we have a
strict policy of landing all changes on master that fit there or can we
be more flexible about where things land and then cherry-pick? Do we have
any use for merges with this plan or is it all cherry-picking? (I'd ask
about rebasing but I fear the reaction to that). And what mechanisms can we
employ, human and technological, to ensure that changes propagate where
they should and important commits don't get lost in the master firehose.

SO, with that, I'm proposing yet another meeting, a separate one, for
those interested in trying to hash out enough of the details that we can
present a plan that's complete enough to be able to vote on.

Because I really don't want another 6am I'm using 1 hour later than our
regular slot, ~1 day 7 hours the time of this post.

9:00 PM Friday, 24 July 2015 UTC:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Release%20plan%20bikeshed+2015-07-24&iso=20150724T21

Hangout on Air for participants:
https://plus.google.com/hangouts/_/hoaevent/AP36tYdv26U8GY0wS7lCe9wMCCORdt4c7-QzcKxnko5q80UDKfK51Q

YouTube feed for lurkers and watching later:
http://www.youtube.com/watch?v=JwwTZIRUoHA

This is not restricted to the TSC if you think you can make a valuable
contribution to this; just be aware that (a) we have a limit on the number
of people that can join the HOA and (b) some of us are sick of endless
discussion about this topic.

Pinging @nodejs/tsc https://github.com/orgs/nodejs/teams/tsc, and
particularly @trevnorris https://github.com/trevnorris, @jasnell
https://github.com/jasnell, @mikeal https://github.com/mikeal,
@chrisdickinson https://github.com/chrisdickinson, I hope y'all can
make it.

—
Reply to this email directly or view it on GitHub
#2230.

[bnoordhuis]

I'll try to make it.

[rvagg]

For further context, I have a blog post up https://medium.com/@nodesource/essential-steps-long-term-support-for-node-js-8ecf7514dbd about the current LTS plan and how it fits in with the current thinking around the release process.

I think this clarifies the model a little:

I'm not suggesting that master-as-unstable is locked in as the plan but it's currently looking like the most viable option and modelling it is much simpler than trying to do next/master flip flop.

[orangemocha]

11pm here, I won't be able to make it. I have full confidence in your ability to nail this down 😄
Looking forward to seeing the policy documented somewhere so that all collaborators know what to do....

[PinkaminaDianePie]

@rvagg only one upgrade of v8 for half of year? Or it will be upgraded with minor versions?

[mikeal]

@PinkaminaDianePie only one major release with a new v8 every year. the plan is to do regular alpha releases of master which will take v8 on a faster schedule.

[Fishrock123]

@PinkaminaDianePie

It's not possible to upgrade v8 faster, or to do it in minor versions. v8's c++ API is constantly breaking in their N.N.0.0 versions, and routinely breaks large parts our c++ and c++ bindings.

The plan:

Have a dev branch which upgrades v8 asap. There will be coinciding releases of this Branch, probably marked as "dev" or "beta". The warranty on using native (c / c++) addons if you use this branch if void, since v8 routinely breaks these in major ways.

Stable branches that cut off of dev every 6 months and bump the major. Minor and patch level fixes continue to also be landed here.

Every year cut a LTS release of of one of the two stable releases (always an even or odd major release). Essentially maintenance only.

[mikeal]

beautiful graph, can we get it under a CC license so we can stick it directly in the weekly update?

[PinkaminaDianePie]

@Fishrock123

There will be coinciding releases of this Branch, probably marked as "dev" or "beta".

this was exactly i worried about. i remember that one of the main problem of old node was very slow update of v8, and iojs switched to more frequent updates. in the last few years javascript evolves significaly and support of new features will be good out of box. even ecma changed numeration of standarts with year instead of number, so probably new standarts will be shiped every year and upgrading v8 is in high priority for some users of node.

[Fishrock123]

this was exactly i worried about. i remember that one of the main problem of old node was very slow update of v8, and iojs switched to more frequent updates. in the last few years javascript evolves significaly and support of new features will be good out of box. even ecma changed numeration of standarts with year instead of number, so probably new standarts will be shiped every year and upgrading v8 is in high priority for some users of node.

Right. Sure. I also agree with using up-to-date v8. We'll have official releases of the "dev" (master) branch that will be stable (except for native modules), and when we cut a stable it will use whichever stable v8 has been in for a few weeks to make sure native addons can be caught up for a stable release. :)

The unfortunate problem here is that v8's c++ API just breaks too much. It's not manageable for the ecosystem and it's barely manageable for core sometimes.

Bottom line is: if that's what you can't live without you'd need to hire full-time people for us who:

1. Update core and NAN.
2. Update the ecosystem for module authors.

I'm sorry it can't be better, we've already talked to the v8 team and they are in no way interested in keeping a more stable c++ API, because their real priority is chrome. :|

(You could argue "don't use v8", but then you really need to be dedicating yourself to moving us off of v8, full-time, long-term. :/)

[mikeal]

Some other important differences:

• Node.js had a default branch of the current release while master lead as the next major.
• Node.js did "alpha/beta" releases as full odd numbered releases and did them very infrequently.
• Even though master was the next major release it didn't regularly take a new v8.

The plan here is to have master be the default branch PR's land in and regularly cherry-pick to stable releases (probably weekly) and to also regularly (probably weekly) produce alpha releases of the next major off of master.

New v8 will be taken regularly in master and alpha releases produced. Community members who want new v8 features on a regular basis can pull from this alpha channel and we're actively trying to keep it stable enough for you to depend on, you're just going to need to stay away from native modules because that ecosystem won't likely be keeping up as fast as you are.

[rvagg]

@mikeal CC-BY version

https://cldup.com/lMHtbE3Nrx-3000x3000.png

[trevnorris]

Do we have a strict policy of landing all changes on master

We can't. There will be more than a few patches that only pertain to the active stable release. Especially if that release will become an LTS, we can expect patches to land right up until we no longer support it.

Do we have any use for merges with this plan or is it all cherry-picking?

I'd prefer taking the cherry-picking route to start, but have no problem re-visiting it if it's found to be impractical.

And what mechanisms can we employ, human and technological, to ensure that changes propagate

I believe we discussed using Labels on PRs to make sure they are migrated properly. It may work well to have the rules that any PR that should propagate be left open until all listed labels (e.g. for-stable) have been done.

We should make special note of the overlap of stable releases, and what this implies. That each next major will have some support overlap with the previous to make sure everyone can migrate properly (e.g. module authors).