What is the schedule for the LTS WG Meetings? We should get this kicked off soon.

To ease the pain for users switching from 0.10 and 0.12 to LTS we need to provide better documentation, currently we have very little.

There's two main areas:

• Breaking changes: listed as things you must pay attention to in your applications because stuff will break.
• Additions that are not necessarily breaking but are interesting because:
  1. they add interesting & useful features
  2. they change behaviour in a way that's not breaking but may be unexpected (e.g. lower memory usage for TLS)
  3. they present a potential risk for breaking existing usage—the fact is that we can't test every workflow & use-case of Node so we honestly can't say that any change won't be breaking for some user, this is where this list is most helpful to large users who are risk averse; if we give them insight to the areas that have changed they at least know where to look.

C++ API changes are another part of this but obviously. Can be fleshed out with NAN 2 docs if necessary

Dot-points with links to pull requests would be enough to get started. Probably also worth doing this in the LTS wiki.

Some of the existing resources:

• https://github.com/nodejs/LTS/wiki/Breaking-changes-between-v0.12-and-next-LTS-release
• https://github.com/joyent/node/wiki/API-changes-between-v0.10-and-v0.12
• https://github.com/nodejs/node/blob/master/CHANGELOG.md#summary-of-changes-from-nodejs-v01035-to-iojs-v100
• https://github.com/nodejs/node/issues?utf8=%E2%9C%93&q=is%3Aclosed+label%3Asemver-major
  https://github.com/nodejs/node/issues?utf8=%E2%9C%93&q=is%3Aclosed+label%3Asemver-minor
• https://github.com/nodejs/nan#api (there's a lot of stuff if you follow the links, no need to copy/paste it but can link)
• https://v8docs.nodesource.com/ (used heavily by the NAN docs)
• nodejs/nan#376 (I have a migration guide for NAN 2 in progress, hopefully published soon)

If you start working on any of this, please keep us informed in this thread so we don't end up overlapping work.

Proposal: LTS Releases should be assigned a more user-friendly name in addition to the semantic versioning number.

@rvagg suggested drawing the names from the periodic table of elements (http://www.ptable.com/). For example: Node.js 4.4.1 Hydrogen. For each upcoming LTS release, the LTS WG would select a short list of candidate names and allow the community to vote on the name.

Other naming schemes are possible, and it's easy to bikeshed endlessly. Let's just pick one and go with it. I'm +1 on @rvagg's suggestion

/cc @cjihrig @nodejs/lts

I don't understand where is the better discussion place. But I would like to raise a problem for LTS release directory.

I am a maintainer of nodebrew, nodebrew is a version manager for Node.js.
I have a problem to implement an option to get latest LTS release.

problem

currently nodejs.org/dist and nodejs.org/download does not have lts directory. so nodebrew command does not recognize which version is latest LTS version. As this blog, LTS version will be even number and Stable version will be odd.

I can recognize LTS version to parse the version number but I don't want to parse the number to implement easily and some even version may not be LTS version in the future.

hokaccha/nodebrew#47

solution

We need lts directory like nodejs.org/dist/lts or nodejs.org/download/lts.
For example:

dist/
  |- lts/
       |- latest
       |- v0.10.xx
       |- v0.12.xx
       |- v4.x.x

or

dist/
  |- lts/
       |- latest
       |- argon
       |- boron
       |- ....

Time: 8PM Monday June 29th UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-06-29&iso=20150629T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/14OBAvjdepzp3RuHUANYprjQ0x2IJE1N6UichGhT4I_s (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYcB-P4p0RYPL6vcX38Zv-uheX6EjnLFCgO86NjF-FnCsYX8DQ _(I've set this up under NodeSource so we can have maximum capacity, 15 people I think, just in case)

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=lOSNxWtE0vU

Current invited participants, this list is not exclusive if you think you should also join, just be aware of capacity constraints and jump on the YouTube feed if you just want to observe and interact with participants via IRC:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

There is a calendar entry for this, if you're not on it and would like to be please ping @misterdjules I think.

Agenda discussion can happen in here first I guess then someone can try and form an agenda in the document before the meeting. It's 6am for me so I'm unlikely to be able to come up with the final agenda before the meeting starts.

Invited:

@nodejs/lts WG members

Participation

Google Hangouts on Air for Participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYfIcvFeHfG5pcWDl9DmR4kXlcLfoEcFiSHdRKxhKcfkJQEELQ

For observers: https://plus.google.com/events/c2i68prcaqmcqjjsavusm4k12b4

Agenda

nodejs/LTS

• Charter this #48
• Schedule for v0.10.x and v0.12.x Releases #52
• tls: make server not use DHE in less than 1014 bits #49

nodejs/node

• Feature/clang format #3612

I should have written this more earlier, the difference of support policy between OpenSSL and Node LTS. openssl-1.0.2 support policy has just come out today as https://www.openssl.org/policies/releasestrat.html
The map table of each support end is the follwing.

What was worse is that node-v0.12 cannot continue to support by 2017-04-01 in regarding to openssl-1.0.1 support end. And the issue in the future is that we have to upgrade openssl-1.1.0 before release of Node on 2017-10-1 but I think it depends the actual release date of 1.1.0. It is API/ABI incompatible to 1.0.2 so that upgrading to 1.1.0 leads a major version up of Node.

I think there are 3 options to go for node-v0.12

• Change the date of LTS support of node-v0.12 to 2016-12-31 to meet openssl-1.0.1.
• Upgrade openssl of node-v0.12 to 1.0.2 which has API/ABI compatible to 1.0.1.
• Accept 3 months support blank.

Thoughts?

Time: 8PM Monday September 14th UTC (1pm Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-09-14&iso=20150914T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/10RKDaijNGt2thmAcTHCRUzNOz9NcZNBbdklyzHXH9yo (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Previous minutes: https://docs.google.com/document/d/19muenxtvm_7_nOfO_aDtpMJBL3HzKGQXG1vQIrnumEY

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYfCVQmo0LEmp7GD72CwuwdfaKhiSJ-vuQDYO57BNWgf8UX2QA

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=7-xWpSE7xEo

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295
• @zkat

Agenda discussion can happen in this thread.

This might be controversial and perhaps the answer is a simple no. One of the advantages of an LTS branch for companies that are extending Node/io.js is that they have a stable foundation to work on.

Two examples of this are:

• IBM's extension of Node to support their architectures which aren't (yet) supported by V8, under io.js policy we're not floating significant patches against V8 so probably not acceptable for us to merge in their changes to the standard releases. We're also upgrading too quickly because they'd need to be constantly adapting to new V8 versions with their radical changes, which is painful.
• Joyent add mdb support to Node.js, but this is a non-trivial exercise and takes quite a bit of effort. I suspect a large part of their reluctance to embrace newer V8 versions or faster V8 upgrade cycles is to do with the difficulty of make it work with mdb.
• There are others that I'm aware of but the pattern is the same.

With an LTS, we have a stable V8 to work with which makes it easier for companies to use as a foundation for additional changes.

So the question is - do we accept additional features into an LTS branch? If IBM came along with POWER support or Joyent wanted mdb support would we be willing to even discuss it or are these pure base-releases and any extension has to happen in a release channel that they create on top of what we release? The version numbering would obviously be kind of awkward because we're likely talking about feature additions, therefore minor-version bumps, but I'm sure we could get creative with this (maybe we claim the next minor-version bump for an LTS and standard releases have to bump two minor-versions to continue).

Discuss.

Topic for discussion, potential WG meeting agenda item. Coming out of nodejs/node#3461 /cc @thealphanerd, @trevnorris.

• AsyncWrap is an undocumented feature that we've allowed to break and evolve prior to being documented and made properly "public"
• It's a useful feature and may already be in use in user-land
• When it becomes more widely used in v5.x and beyond, the lack of parity with v4.x will be a big problem if we don't keep it updated
• If we go all the way and keep parity and even add documentation then it's likely a semver-minor, is that OK for LTS or is there a half-way we can pull off to keep it at parity but technically not a feature addition (like not adding documentaiton)?

A quick report from @trevnorris on its status and how close to final(ish) it is would be helpful here.

The intention of this issue is to bike-shed the specifics of how we maintain a release. This could actually be quite simple but I want to make sure we think this through properly.

How do we name these things?

For the NodeSource Linux repositories for Node, I made the call that we should start splitting them up by name and branch. Both the setup scripts and repo directories have these names and the pattern we're using should work for io.js LTS releases (in fact I was imagining LTS at the time).

• iojs_1.x - for all standard releases with 1 as the major version, it'll become deprecated at some point we we'll encourage everyone to move on but they'll have to opt-in like we're doing for Node.js 0.10 -> 0.12.
• iojs_2.x - for the next series of standard releases with 2 as the major. You have to run a separate setup script and download from a separate repo to get these.
• iojs_1.9.x (or perhaps with an -lts in there?) for LTS releases based on the 1.9.x series, again you have to opt-in to this repo to get them but once you're in all you get is 1.9.x.

i.e. I'm suggesting simply 1.9.x as how we label an LTS, possibly with an lts in there somewhere.

Where to we release to?

Do we just make a 1.9.x branch under https://iojs.org/dist/ for a 1.9.x LTS branch?

How do we label LTS releases?

• Do the files and directories just get named exactly as we're naming standard versions or do we put an lts in the name somewhere? iojs-v1.9.32-lts-linux-x64.tar.xz, does it matter?
• Do we have anything in the executable that identifies it as an LTS? Perhaps something in process.versions?

Do we have a completely separate group of people that are authorized to cut an LTS release to standard releases?

My feeling is that the LTS WG would end up having its own, separate discussions, maybe even moving discussions from iojs/io.js to this repo in some cases, therefore people deeply involved in LTS should be responsible for cutting the releases because the field of responsibility is entirely different. But perhaps I'm over-thinking.

Anything else we need to discuss?

Following up from @zkat's comment in the summit repo about npm 2.x LTS: openjs-foundation/summit#1 (comment) we should pull that discussion into here because we're going to have to care about this for 0.12 maintenance at least. We should ensure that we have synchronized goals and ideas about what LTS means so that we don't end up in conflict about what we're happy to pull in for npm for LTS releases.

@zkat perhaps you could tune us in to ongoing discussions about npm LTS or maybe someone over there could join our meeting next week to sync? Monday 1pm PT.

I see no mention of Nan in this repo, while it is a critical component of my daily maintanance of modules.

I think Nan should support all current LTS releases. It is probably implied, but probably it is worth specifying it for newcomers.

Hi!

Apologies if this has already been covered elsewhere. I'm going on the assumption that support (e.g., security fixes) for v0.8.x will be dropped (unless that's happened already?) I can't find any explicit statement about this anywhere, but it seems to be the case and it's not included as an LTS release (which is good!).

I'm asking because I want to know if and when I can stop including a v0.8.x in the Docker node image (nodejs/docker-node#34). It should be noted that once dropped, users would still be able to pull a node v0.8.x image from the registry (e.g, docker pull node:0.8.28 or docker pull node:0.8) there just won't be any 0.8 updates once I drop it from the GitHub repo.

Just FYI, this is the current proposed timeline for next Debian stable:
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-September/011202.html

Due to tight timings (and unless other changes of plans), we will probably target 4.4.1.

@nodejs/lts I'm really sorry that I messed up the meeting this week, it should have been today (yesterday) but I completely forgot after a computer-free weekend and a zone-out of all things Node. It's vital that we have a meeting next week because we have to ship v4 LTS only days afterward! A meeting this week would have been ideal. On that note, I'd like to ask if someone else would mind taking over meeting planning and organisation for this WG? The timing is really poor for me and I need to hand off some of my existing workload anyway. Perhaps @jasnell?

Time: 8PM Monday October 5th UTC (1pm Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-10-05&iso=20151005T20 PLEASE NOTE DAYLIGHT SAVING SHIFT FOR SOME TIMEZONES

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/1DOcI2B8F0nuoz2hf6uidCrAG0N067YEAR192ljguJhc (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Previous minutes: https://docs.google.com/document/d/10RKDaijNGt2thmAcTHCRUzNOz9NcZNBbdklyzHXH9yo

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYe1gWyx4ZbW2Uyl4oVBMn2ZgRw_viokqpxw5gjFHwnkJr9rfw

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=wfg2nHXAQqI

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295
• @zkat

Agenda discussion can happen in this thread.

Time: 8PM Monday July 13th UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-07-13&iso=20150713T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/1kOAduxpRcB_nzh0dHqPDfOdC3ZoAY6wmCYAR4rLbROg (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYeCfFDqFZhOC4nBHdDAtnR2AttppoyDpqTJtJdey2UOFAQWJA

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=A4PMkEnt1Ak

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

Do you have any thoughts on documenting LTS on nodejs.org? As soon as v4 LTS and v5 has been released, I think we should at least have an LTS section on the downloads page documenting what LTS means alongside the LTS release schedule plan graphics. Maybe even pros / cons lists for both v4 and v5.

Appreciate all the help we can get on this while preparing nodejs.org for these two release lines in nodejs/nodejs.org#200.

@nodejs/lts ... See: tls: make server not use DHE in less than 1024bits ... from what I understand, this would technically be a semver-major.

@shigeki @mhdawson ... which versions are affected by this? is it only v0.12.x? or v4.2.x also?

As a followup to a discussion I had with @jasnell and @Fishrock123 on Twitter, I'd like to help this WG and the TSC figure out how the 0.10 release series deals with npm. For the most part, @zkat is the npm CLI team member responsible for our LTS strategy, so this is mostly just to capture the discussion I was having with James and Jeremiah on Twitter, and maybe give Kat some additional context.

The npm CLI team would like to officially discontinue support for npm@1. There hasn't been a new release of [email protected] since September 13th, 2014, and at the time that [email protected] was released, the npm team didn't plan on continuing to support npm@1 development beyond the release of [email protected] on that same day. Our policy as a support organization has just been to ask people who encounter one of the many issues with [email protected] to upgrade to npm@latest as a first step, so npm actually stopped supporting npm@1 a long time ago.

[email protected] is very familiar to many, if not most, Node users, because it's been bundled with Node.js 0.10 since 0.10.32 was released on September 16th, 2014. At the time [email protected] was released, there were concerns expressed about including an npm including breaking changes in npm in the middle of a stable Node release series. This frustrated me at the time, but in retrospect it looks pretty reasonable.

A lot of changes have been made to npm since then (including several security fixes that affect users of [email protected]), so as we think about moving Node 0.10 into LTS, it's worth taking another look at this and figuring out how to handle npm LTS in a way that works well for the LTS WG and for users depending on stability in 0.10 LTS.

Concerns

The main areas of concern are npm@1's lack of forward compatibility with npm@>=2 features and the primary npm registry, fixes to security flaws in npm@2 that also affect npm@1, and changes included in npm@2 that might have an adverse impact on LTS users of the version of npm bundled with Node 0.10.

Forwards incompatibility of npm@1 with scoped packages

One of the most significant changes in npm@2 is its support for scoped packages. There was a lot of deliberation around the design of scoped packages, and the choice of the format @scope/name for scoped package names was designed to cause as little hassle for users as it possibly could.

Unfortunately, since we didn't plan for npm@1 lasting beyond the rollout of scoped packages, we didn't do much testing of what happened when users tried to install scoped packages with [email protected]. It turns out that npm@1 ignores the leading @ in scoped package names and treats the rest as a GitHub shortcut, which can result in the very confusing situation of a user thinking they've installed an npm private package they shouldn't have access to, when in fact they've installed a package from GitHub (which might not be the package they were expecting).

In addition, the registry changes to support private packages include a switch from using HTTP Basic authentication to bearer tokens (and also changes when authentication information is sent with npm requests – the registry needs to know who's making a request to decide if they're entitled to view any information on private packages). npm@1 is increasingly ill-equipped to deal with current registry architectures, which includes not just npm, Inc's registry (and its npmE on-premise registry product), but also third-party registry projects that have added their own support for scoped and private packages, like sinopia, cnpmjs, and (I believe?) Artifactory.

The support for scoped packages is itself not a breaking change, but backporting all of the necessary code from npm@2 to npm@1 (including all the fixes made related to scopes since [email protected] went out) is enough work to render supporting scopes in npm@1 practically infeasible.

Security fixes in npm@2 affecting npm@1 users

As I mentioned above, there are a few security fixes in npm@2 that affect npm@1 users. I think / hope this is everything, but it's possible I overlooked something:

• b9474a8 [email protected]: Stop publishing build cruft (config.gypi) and per-project .npmrc files to keep local configuration out of published packages.
• 300834e [email protected]: Normalize symbolic links that point to targets outside the extraction root. This prevents packages containing symbolic links from overwriting targets outside the expected paths for a package.
• 0dc6875 [email protected]: Package versions can be no more than 256 characters long. This prevents a situation in which parsing the version number can use exponentially more time and memory to parse, leading to a potential denial of service.

Since the fix to semver was made to a version of semver that includes one of the breaking changes included in npm@2, addressing it in npm@1 wouldn't be as simple as updating npm to use a newer version of semver – it would be necessary to fork semver@2 and backport the fix to it.

Breaking changes in npm@2

The changes most pertinent to LTS discussions are in bold.

• df4b0e7 #5518: support passing arguments to run scripts.
• 4378a17 [email protected]: prerelease versions no longer show up in ranges; ^0.x.y behaves the way it did in semver@2 rather than semver@3 (ea547e2 in semver@3: ^0.x.y was functionally the same as =0.x.y).
• c2cccd4 / npm/npm-registry-client@ba6b73e [email protected]: npm/npm-registry-client#92: Move /whoami endpoint out of the package namespace (to /-/whoami).
• c6ddb64 npm requires Node >= 0.8.
• 021770b lifecycle: do not add the directory containing node executable.

Possible solutions

Here are two ways we could fix this problem for 0.10 LTS:

Include npm@2 in 0.10 LTS

The npm CLI team is getting close to making npm@3 the version of npm intended for general use. It's had a lengthy development cycle and a pretty extensive beta, but since it includes a nearly complete rewrite of the installer, we've planned from the beginning of the npm@3 beta to support npm@2 and npm@3 in parallel, probably for at least six months. This makes it a much easier thing for us to support going forward (in fact, right now I'm planning on npm@2 being the npm major version included in Node 0.12 and 4.0 LTS, assuming both of those have LTS support). In addition, it includes all the security fixes and also works much better with current npm registry architectures.

That said, it's up to the LTS WG and the TSC to decide if the breaking changes enumerated above are low-risk enough to justify inclusion in LTS. I like this solution because it requires much less work from the CLI team, and we've actually planned to support npm@2 for a while anyway.

Release an [email protected] that encourages users to upgrade to npm@2

As I hope I've made clear, backporting the security fixes and forward compatibility changes necessary to make npm@1 usable without including any breaking changes is more than the CLI team is able to take on. However, it would not be very difficult to put together a new version of [email protected] that includes two changes:

1. Exit with an early error and a helpful message if users attempt to install scoped packages.
2. Every time the CLI is run, print out a deprecation warning strongly encouraging users to upgrade to at least npm@2.

That would address the most significant forwards compatibility issue, along with making it fairly easy for users to figure out what they need to do in circumstances where they're blocked.

These are just ideas I've come up with, and the team is open to other suggestions.

So that's the story with 0.10. If the WG decides that some form of including npm@2 is the way to go, @zkat, as npm@2 maintainer, will be the npm point of contact. If the WG decides to stick with [email protected], I'm probably the best person on the CLI team to handle things, as I'm the member of the team who's got the most familiarity with its code. Kat and I are both happy to participate in discussions related to this and show up for LTS WG and TSC meetings discussing them. Just let us know where we're expected and when and we'll be there.

James is a away and he asked me to run the meeting today.

He mentioned he was going to send out a recurring meeting but I've not seen it so I'm opening this issue.

Event page: https://plus.google.com/events/c97bmu1q4o0g6fteodudpvln94s

Hangouts link for participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYdbK7VQEIgf8PfFeEkV5dHdCZ3ba2j4e1kR_g-OC3upzhqVWg?hl=en&authuser=0

Link for those who just want to watch: http://youtu.be/_d6nvm_cCgs

@nodejs/lts ... Scheduling the LTS meetings this past few weeks has been a bit problematic due to holiday/vacation schedules and conflicts. Next week many of us will be heading to Portland for Interactive on Monday. I propose that we schedule the next LTS meeting for the following week -- Monday December 14th.

As an ongoing effort, we need to be actively soliciting input on LTS requirements from the node user base. Let's use this issue to track the effort.

(Carried over from nodejs/dev-policy#67)

Time: 8PM Monday July 27th UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-07-27&iso=20150727T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/1idBumRq1CLC0CSSIOfjCfzGlwyFEsX22JoNgniyefIw (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYfous8vsoKUuI_1hun0KgIq0ejqG25fN8xCG3MNunq-YW271Q

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=b7o3__Jk2FI

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

Previous meeting minutes: https://docs.google.com/document/d/1z0J_5G3c62REKG-bt6MAe6TCpD5U6tz2EmKeVcA20SQ

The intent of this issue is to gather some initial discussion on how to run a TLS process. Ultimately this is up to the working group to decide but feedback is important here.

I don't think this needs to be pinned down firmly any time soon, we can start simple and ease in to it, ramping up the serious as we go along and work it out. That would be my preference anyway. For instance, I'd like to propose that our first LTS is very soon, perhaps to coincide with the next V8 release, and we announce support for only 3 months with the option of extending that later on. Then we can build momentum around the process and iron out any wrinkles. Beyond that, we can brainstorm some possibilities of how this is run.

These are just some options that come to mind for me to start the discussion.

Option 1: Major-version-based LTS releases

In this option we would run an LTS branch as soon as the first minor is bumped after a major, and we'd stick with only patch releases in the strict semver sense. How long they are supported is a matter for further discussion.

One positive about this is that it's easy to understand and communicate.

There are multiple negatives though. It assumes we'll have major-version bumps regularly, which may not be the case given the pain they're going to cause. We also can't do anything time-based with these branches other than how long they exist for.

Example

1. Standard io.js release train moves from 2.0.4 to 2.1.0, an LTS is triggered.
2. A 2.0.x branch is created to run the LTS.
3. 2.0.5 is cut as soon as there is something to warrant it, all patch releases from 2.0.5 onward are part of the LTS.
4. Standard releases continue as usual.

Option 2: Regular time-based, non-overlapping LTS releases

In this option we would have a time period that would trigger a release, perhaps 6 or 12 months. This would be a little like the way Ubuntu does standard releases (not LTS). At the appropriate date, we would take the current major.minor and use that to start an LTS branch. There would be a period of time where there's overlap between standard and LTS so we probably wouldn't end up making actual LTS releases until the next minor bump for standard releases.

Example

We're doing a 12-month cycle starting 1-May each year.

1. Standard io.js release train is at 1.9.2 as we roll over in to May.
2. As soon as there is a major-version bump to 1.10.0 we create a 1.9.x branch and LTS starts where standard releases left off in that minor.
3. Standard releases continue as normal.

Option 3: Regular time-based, overlapping LTS releases

In this option we do the same as the previous but we are maintaining multiple LTS branches at the same time. The overlap allows people a smoother upgrade path than the strict stop/start of option 2. The amount of time we run an LTS differs from the amount of time between creating an LTS branch. Perhaps 18 months for the lifecycle and 12 months between each LTS branch creation, giving a 6 month window for upgrading between LTS.

Variation 1: Time period is the same as the amount of time between creating an LTS branch but we run 2 (or more?) LTS releases, staggered by 6 months, so we're always creating a new LTS each 6 months and run them for X months each, where X could be 12 months or more.

Variation 2: We have two different classes of LTS and we create something similar to the Ubuntu process. We have a long-running one one that runs for a shorter time. So for example, we could make a new LTS every 6 months like Ubuntu does and only support them for 6 months but every X LTS branch is supported for an extended period, perhaps every 3rd gets supported for 24 months or more.

Discussion

So, given those ideas, let's discuss LTS models that we know work well in the wild and how we can adapt those ideas to what we have to work with in io.js.

The major concern I have with io.js is that supporting V8 for longer than a stable version of Chrome is going to be on our heads. However, it's somehow managed to work for Node.js 0.10 for >2 years now so perhaps it's not going to be all that hard. I think the main risks are security-related, we'd be the only eyes supporting that codebase so we'd better have people that understand it.

There is also the issue of possible extension of LTS. There was a suggestion, floated early in the life of io.js (or was it node-forward?) that "if someone wants to contribute then the can keep a branch alive", or something to that effect. I'm uncomfortable with the looseness of this approach because it becomes difficult to communicate exactly what kind of support a particular release train has from the io.js team. I would rather leave it to the LTS WG to make decisions about precisely what the lifecycle of an LTS branch is and if, for instance, a company was to step forward and say that they are willing to throw engineers at a branch to make it live for 5 years and the LTS WG became convinced this was possible and acceptable then they could make it happen. The alternative is to let people release their own versions outside of the official io.js banner, which may work great for situation like IBM wanting to continue releasing POWER-specific versions beyond a standard LTS cycle. This is all open for discussion of course.

@jasnell asked the question a while ago whether a v0.14.x LTS cycle would be needed before moving to using nodejs/node to release LTS releases.

The main reason I believe for this question is there's a significant amount of uncertainty from users of the current stable release of Node.js about what will break when they upgrade to the next LTS releases that will come from the merged repository.

What I had suggested at that time was that we:

1. Document what the breaking changes would be for users switching from v0.12.x to a release from the converged repo.
2. Reach out to the broadest set of representative users as we can to identify critical concerns on such a migration.

And finally we would use the outcome of step 1 and 2 to make a decision whether a v0.14.x is needed. I would expect it's not needed, but we'll be able to provide a smoother transition path by documenting breaking changes better, and fixing some issues ahead of time.

I made some progress on step 1 and put together what I think is a list of breaking changes between v0.12.x and what will be the merged nodejs/node repository.

Before moving to step 2, I would like as many members of @nodejs/lts as possible review that list and comment in this issue.

/cc @nodejs/lts

@nodejs/lts ... please offer candidates for the codename for the first LTS release.

as far as I'm concerned, the obvious first choice is hydrogen.

@nodejs/lts ... preparing for the v4.2.2 LTS Maintenance release... Here's the list of candidate commits currently sitting in v4.x-staging. Please let me know if any of these SHOULD NOT be in the v4.2.2 release (https://github.com/nodejs/node/commits/v4.x-staging)

List of commits in v4.x-staging: #50 (comment)
List of commits remaining in master: #50 (comment)

/cc @nodejs/collaborators

Time: 8PM Monday August 17th UTC (1pm Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-08-31&iso=20150831T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/10RKDaijNGt2thmAcTHCRUzNOz9NcZNBbdklyzHXH9yo (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Previous minutes: https://docs.google.com/document/d/19muenxtvm_7_nOfO_aDtpMJBL3HzKGQXG1vQIrnumEY

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYcJC3n1Ap1J3KqgHIeUAF1oD4CuJxv8mAAQLen2l10gYB-YMw

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=Dgg3x7E2Vgs

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295
• @zkat

Agenda discussion can happen in this thread.

@nodejs/lts ... putting out the call for agenda items now!

Time: 8PM Monday October 19th UTC (1pm Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-10-19&iso=20151019T20 PLEASE NOTE DAYLIGHT SAVING SHIFT FOR SOME TIMEZONES

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/156bztXDR1CoPAU8BzCKCbgU-9IYTprk__aNsd0N1G0Q (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Previous minutes: https://docs.google.com/document/d/1DOcI2B8F0nuoz2hf6uidCrAG0N067YEAR192ljguJhc/edit#

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYe1gWyx4ZbW2Uyl4oVBMn2ZgRw_viokqpxw5gjFHwnkJr9rfw

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=wfg2nHXAQqI

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295
• @zkat

Agenda discussion can happen in this thread.

Thanks to @thealphanerd for a champion effort in merging a bunch of commits in to v4.x-staging we now have a pretty good list to look at and discuss whether there's anything we might consider inappropriate for the next LTS release. I believe that all of these commits fall after v5.0.0 so have not been included in a stable release yet so they still have that hurdle to go through. The important part is the discussion so we can further refine our criteria for what should make it in to LTS and what shouldn't. So if anything in this list stands out as a potential concern then please raise it for discussion. @thealphanerd perhaps you can fill us in on any borderline commits that didn't make it but may be worth discussing?

branch-diff v4.x v4.x-staging --group

• [935b8be8f6] - Add missing va_end before return (Ömer Fadıl Usta) #3565
• [aef3d549af] - build: fix configuring with prebuilt libraries (Markus Tzoe) #3135
• [e86817cf81] - cluster: send suicide message on disconnect (cjihrig) #3720
• [c37a560df4] - crypto: Improve error checking and reporting (Stefan Budeanu) #3753
• [44d4a02694] - deps: upgrade npm to 2.14.9 (Forrest L Norvell) #3686
• [a632db5ba6] - dns: prevent undefined values in results (Junliang Yan) #3696
• [877d86d32d] - doc: add link to [customizing util.inspect colors]. (Jesse McCarthy) #3749
• [65267bcdec] - doc: sort tls alphabetically (Tristian Flanagan) #3662
• [46356965ff] - doc: sort stream alphabetically (Tristian Flanagan) #3662
• [600bc56561] - doc: sort net alphabetically (Tristian Flanagan) #3662
• [256467208e] - doc: sort process alphabetically (Tristian Flanagan) #3662
• [e6704393f6] - doc: sort zlib alphabetically (Tristian Flanagan) #3662
• [57f298f482] - doc: sort util alphabetically (Tristian Flanagan) #3662
• [cb62bb2a1b] - doc: sort https alphabetically (Tristian Flanagan) #3662
• [2cac10d9c0] - doc: sort http alphabetically (Tristian Flanagan) #3662
• [133f84e352] - doc: sort modules alphabetically (Tristian Flanagan) #3662
• [fdeaec50d3] - doc: sort readline alphabetically (Tristian Flanagan) #3662
• [45f7d75c61] - doc: sort repl alphabetically (Tristian Flanagan) #3662
• [babc561cbf] - doc: sort string_decoder alphabetically (Tristian Flanagan) #3662
• [cf96a53520] - doc: sort timers alphabetically (Tristian Flanagan) #3662
• [ea66bd3a54] - doc: sort tty alphabetically (Tristian Flanagan) #3662
• [fd2e926313] - doc: sort url alphabetically (Tristian Flanagan) #3662
• [0814b8c0c9] - doc: sort vm alphabetically (Tristian Flanagan) #3662
• [d7b685c63f] - doc: sort querystring alphabetically (Tristian Flanagan) #3662
• [84b9376b45] - doc: sort punycode alphabetically (Tristian Flanagan) #3662
• [78277495df] - doc: sort path alphabetically (Tristian Flanagan) #3662
• [bbd00ee296] - doc: sort os alphabetically (Tristian Flanagan) #3662
• [806b6944fc] - doc: sort globals alphabetically (Tristian Flanagan) #3662
• [fc346fb209] - doc: sort fs alphabetically (Tristian Flanagan) #3662
• [1f644b1b5a] - doc: sort events alphabetically (Tristian Flanagan) #3662
• [c8ba5570d9] - doc: sort errors alphabetically (Tristian Flanagan) #3662
• [128d100a0a] - doc: sort dgram alphabetically (Tristian Flanagan) #3662
• [ecfbbf0fb9] - doc: sort crypto alphabetically (Tristian Flanagan) #3662
• [720f068637] - doc: sort dns alphabetically (Tristian Flanagan) #3662
• [1b668b5ce3] - doc: sort console alphabetically (Tristian Flanagan) #3662
• [448523636a] - doc: sort cluster alphabetically (Tristian Flanagan) #3662
• [2c5e7ede79] - doc: sort child_process alphabetically (Tristian Flanagan) #3662
• [2433e3de96] - doc: sort buffer alphabetically (Tristian Flanagan) #3662
• [2f8caaf756] - doc: sort assert alphabetically (Tristian Flanagan) #3662
• [8b6120d84f] - doc: add note on tls connection meta data methods (Tyler Henkel) #3746
• [3435f87613] - doc: add note to util.isBuffer (Evan Lucas) #3790
• [a49dd8913c] - doc: add romankl to collaborators (Roman Klauke) #3725
• [5cbfb76919] - doc: add saghul as a collaborator (Saúl Ibarra Corretgé)
• [64e6d06ad7] - doc: add thealphanerd to collaborators (Myles Borins) #3723
• [9970b76623] - doc: update lts description in the collaborator guide (James M Snell) #3668
• [9ce1f75cb7] - doc: add LTS info to COLLABORATOR_GUIDE.md (Myles Borins) #3442
• [d7b4f759c5] - doc: typo fix in readme.md (Sam P Gallagher-Bishop) #3649
• [d410d5856d] - doc: fix wrong date and known issue in changelog.md (James M Snell) #3650
• [5a23bb59ef] - doc: rename iojs-* groups to nodejs-* (Steven R. Loomis) #3634
• [b3b55a5155] - doc: fix crypto spkac function descriptions (Jason Gerfen) #3614
• [bb20abb320] - doc: Updated streams simplified constructor API (Tom Gallacher) #3602
• [08ab9f35da] - doc: made code spans more visible in the API docs (phijohns) #3573
• [98762d2ae1] - doc: added what buf.copy returns (Manuel B) #3555
• [dfc2707097] - doc: fix function param order in assert doc (David Woods) #3533
• [d02365ba83] - doc: add note about timeout delay > TIMEOUT_MAX (Guilherme Souza) #3512
• [4a94c0a06f] - doc: add caveats of algs and key size in crypto (Shigeki Ohtsu) #3479
• [22bfe2297b] - doc: add method links in events.markdown (Alejandro Oviedo) #3187
• [38a5ae1285] - doc: stdout/stderr can block when directed to file (Ben Noordhuis) #3170
• [5689630c84] - docs: fs - change links to buffer encoding to Buffer class anchor (fansworld-claudio) #2796
• [948af717d5] - module: remove unnecessary JSON.stringify (Andres Suarez) #3578
• [486d287c1e] - repl: don't crash if cannot open history file (Evan Lucas) #3630
• [bf489691be] - repl: To exit, press ^C again or type .exit. (Hemanth.HM) #3368
• [550c606428] - src: Revert "nix stdin _readableState.reading" (Roman Reiss) #3490
• [07b57914e4] - test: use really invalid hostname (Sakthipriyan Vairamani) #3711
• [0fb40b4300] - test: Fix test-cluster-worker-exit.js for AIX (Imran Iqbal) #3666
• [2570cb79e5] - test: fix test-module-loading-error for musl (Hugues Malphettes) #3657
• [7009e019af] - test: fix test-net-persistent-keepalive for AIX (Imran Iqbal) #3646
• [c10f17fafd] - test: fix path to module for repl test on Windows (Michael Cornacchia) #3608
• [84f8eb7094] - test: add test-zlib-flush-drain (Myles Borins) #3534
• [75b4613f46] - test: enhance fs-watch-recursive test (Sakthipriyan Vairamani) #2599
• [1064eb6aa8] - util: use regexp instead of str.replace().join() (qinjia) #3689
• [1543c78c12] - zlib: only apply drain listener if given callback (Craig Cavalier) #3534
• [d1cedbd981] - zlib: pass kind to recursive calls to flush (Myles Borins) #3534

Will use this issue to begin tracking best practices procedures for LTS releases. There are a few good post mortem lessons learned from cutting the first one:

• For the initial v4.2.0 cut, because we did not have another stable yet (v5.x), I was a bit more relaxed about landing changes. Unfortunately, those ended up leading to some critical regressions that would have been caught had the change first gone out in either a nightly from master or a stable release. From this point on, I strongly recommend that, with exception to critical security and bug fixes, we do not land any code changes in LTS that have not landed in at least one nightly or stable.
• We seriously need better ecosystem tests. It's time to keep iterating on citgm.

(will add more as we go)

I think the document is fairly low-level, as it assume one knows very well the node/iojs dev cycle, what next is, and all the problema correlated to V8 versions.

Most developers do no have this knowledge, so we should add a TLDR; thing that is easily understandable.

We need to identify the schedule and remaining next steps for getting v0.10.x and v0.12.x releases out.
@nodejs/lts

@misterdjules ... Per https://github.com/joyent/node/wiki/Node.js-release-guide#ssh-keys, my public key for nodejs.org access is below.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDF6MGPtEOVls1KKdhMsvcPPOp0LjViOw3pN9++QGGmk1eK+BHHklGGpiafB6sdfxOPbc2+AG6bMtg85aHkawWxjt/oNocDpK0QJbIrPzP6tJJq5iU0bIzrrup93o1j+BG2/UCYimSWqX3K63BT7uyoDwEPOfNlPL8hHlKOuYM7DQxA7vveundE3TV7s+vlm0VweZe8g+E8iBLHFC0dq8LlMoqcFOhHyGqvKzK5nXXGRelBPXADVkiqCNbO02k3mnL4BzYefghJHHvkTsozXWz5qGAyFquP9dcNiAsSsBuwtSSsMCHHPOlv+gKDtfKhwOkB9eNfX0edy+IVSav27cXki0NSaVq63Zm0r45Jtzgr5nGLxIL0JV4yKMizMkSAK2LOGGZACliaFN63lvfs6P4XgOBI25UWcUHg2KLbPJuk5VMIDB59yd9QMwyRLHhHZYoyfLm1eV6XCrwE1yDei+V54X2zCPFhjFp+aA4iObHCu9w2VfLTnpXRGEuNDspEMzswfT7XrVGbfbItCiF7k3SSuagOyi7oxknXHoqeJqZE5yjJ6BHTpPo9icAuJpUJNq4LduBJboD3yNYPGMR6qYU5VsKI05zSN15mynsst9ZUV0xp5CSUPhYaX9XN4nnreUNzgy2OfC2a+Lmv+2knRHEzH9PBwWXlFFRt4Z2bgcsTww== [email protected]

Some of the community feedback about the LTS plan received at the Node.js Interactive conference was that the messaging around LTS is still too complicated. The labels, "LTS", "Stable" and "master" are a bit confusing. @mikeal, @ashleygwilliams and I had a brief conversation with a couple of folks from the Linux Foundation marketing team to discuss how the messaging can be improved and one of the ideas that came up was relabeling our release branches (e.g. "LTS" would become "Stable", "Stable" would become "Current" and "master" would become "Canary"). Obviously changing the labelling this soon after adopting the current labeling could end up causing even more confusion so we need to be strategic about any changes we decided to do.

Another of the ideas that came up was the notion of creating a formalized, community supported migration guide that would be proactively updated for each major release. The guide would exist as a microsite under the nodejs.org domain (e.g. migrate.nodejs.org) and would offer detailed assistance on how to move from one major node.js release to another, documenting the major changes, offering tips and being prescriptive with a clear migration path. This could be driven either through the @nodejs/documentation working group or through a new working group specifically chartered for stewarding the migration microsite.

Time: 8PM Monday August 17th UTC (1pm Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-08-17&iso=20150817T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/19muenxtvm_7_nOfO_aDtpMJBL3HzKGQXG1vQIrnumEY (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYdal_Po2hhVWvnnnE_vEq1RoByPE58TWJA1z_Ir--k6AVsDSQ

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=u2-BeP7YmU8

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

Previous meeting minutes: https://docs.google.com/document/d/1idBumRq1CLC0CSSIOfjCfzGlwyFEsX22JoNgniyefIw

Time: 9PM Monday November 2nd UTC (1pm Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-11-02&iso=20151102T21 PLEASE NOTE DAYLIGHT SAVING SHIFT FOR SOME TIMEZONES

Agenda and minutes can be collected in here and copied into this repo later:
https://docs.google.com/document/d/1AKPRkmeKEOVZnvN0698JNNgK1Uw4VTBLMA9oFg-oAQ8 (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Previous minutes:
https://docs.google.com/document/d/156bztXDR1CoPAU8BzCKCbgU-9IYTprk__aNsd0N1G0Q

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYe1gWyx4ZbW2Uyl4oVBMn2ZgRw_viokqpxw5gjFHwnkJr9rfw

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=wfg2nHXAQqI

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295
• @zkat
• @thealphanerd

nodejs/node

• deps: backport 9da3ab6 from V8 upstream #3609

nodejs/LTS

• Schedule for v0.10.x and v0.12.x Releases #52
• tls: make server not use DHE in less than 1014 bits #49
• Charter this #48
• npm in 0.10 LTS #37

Agenda discussion can happen in this thread.

Here is my thinking of what we should look for in a potential V8 maintainer:

• Strong C++ and x86/x86_64 assembly skills.
• Familiar with VM technology (pre if they've worked on Hotspot.)
• Experience with Win32 and POSIX application development.
• Experience working with large code bases.
• Background in application security preferable.
• Self-directed.

I can help with on-boarding, high-level concepts, bird's eye view of the code base, etc.

Time: 8PM Monday July 6th UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-07-06&iso=20150706T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/1UPxDfK7uxz6O_WUA6eXHSg_E4f5R5qoBMiFq9NVWn9c (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYe-nqS7Vwr80BaYP-sHDudP_c2cIhN0Znj-d_UaJRntbRl8rw

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=PAdd5T1z9MA

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

I've had several independent inquiries on this: will v0.12 or pre-converged io.js upgrade to npm3 or will we hold off until the converged repo?

@nodejs/lts @nodejs/tsc

Time: 8PM Monday August 3rd UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-08-03&iso=20150803T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/19muenxtvm_7_nOfO_aDtpMJBL3HzKGQXG1vQIrnumEY (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: _I can't attend this meeting, someone who is attending needs to create the HOA_

YouTube feed for observers and saved recording: ...

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

Previous meeting minutes: https://docs.google.com/document/d/1idBumRq1CLC0CSSIOfjCfzGlwyFEsX22JoNgniyefIw

This grew out of the discussion we've been having about the release process. While we are all agreed that the next branch will take new versions of v8 on something close to the v8 release cycle we want to limit the v8 updates that land in master while those updates break native modules.

This means that what is in master will end up having a v8 that is not actively supported by the Google v8 team and will need to be maintained by us. We already have to do this for LTS releases so I'm wondering what the plan is for that and how we can easily integrate an "LTS v8" in to master.

As stated in nodejs/node#3454 (comment), we should write a charter and get the TSC to ratify this group, it's about time. :)

Sorry again, but I can't make this meeting, I've only just got home and my body clock is too messed up, I need at least a day to reset. @jasnell I'll leave it to you to make the call about whether this one goes ahead or not. The OpenSSL question in #31 is an interesting one worth discussing at some point.

Time: 8PM Monday August 10th UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-08-10&iso=20150810T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/19muenxtvm_7_nOfO_aDtpMJBL3HzKGQXG1vQIrnumEY (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: _I can't attend this meeting, someone who is attending needs to create the HOA_

YouTube feed for observers and saved recording: ...

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

Previous meeting minutes: https://docs.google.com/document/d/1idBumRq1CLC0CSSIOfjCfzGlwyFEsX22JoNgniyefIw

Time: 8PM Monday July 20th UTC, or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js%20Foundation%20LTS%20Meeting%202015-07-20&iso=20150720T20

Agenda and minutes can be collected in here and copied into this repo later: https://docs.google.com/document/d/1z0J_5G3c62REKG-bt6MAe6TCpD5U6tz2EmKeVcA20SQ (if you're attending the meeting and don't have write access to this doc please give me your google login email).

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYdqYJ-g9-Gd6Yk-t-MIe1075JAFHWEA5Y5wHhf-AKNd2qOgbQ

YouTube feed for observers and saved recording: http://www.youtube.com/watch?v=4zYTQ64bHd4

Current invited participants, this list is not exclusive if you think you should also join:

• @bnoordhuis
• @dshaw
• @Fishrock123
• @jasnell
• @misterdjules
• @rvagg
• @shigeki
• @trevnorris
• @geek
• @mhdawson
• @ofrobots
• @joaocgreis
• @srl295

Agenda discussion can happen in this thread.

Previous meeting minutes: https://docs.google.com/document/d/1kOAduxpRcB_nzh0dHqPDfOdC3ZoAY6wmCYAR4rLbROg

@nodejs/lts ... At Node.js Interactive, @ofrobots asked if we could explore the possibility of adjusting the LTS runway to achieve better alignment with the V8 stable schedule. For instance, V8 4.9 will be going into feature freeze after this next week, because Node v6 will be cut in April, v4.9 would be the version of V8 that we ship in v6 and ultimately in the next LTS when v6 rolls over next October. Therefore, any semver-major or breaking changes in V8 would have to land by December 18th, 2015 in order to make it into v6 LTS. However, if we shifted our stable release cycle by two months to ship v6 in June, the V8 team would have more time to get in the additional major fixes they would like to get landed before the next LTS rollover in October. Doing so would mean (a) adjusting our stable release cycle and (b) shortening our LTS runway from six months to four months. Obviously this is something that we would need to consider very carefully.

/cc @nodejs/ctc

Bringing this up due to nodejs/node#3609 and nodejs/node#4135, of which we've assessed the impact to be minimal in risk, but great in potential benefit.

Perhaps we could have occasional minor bumps on LTS lines to include these sorts of features we've carefully selected.

I suggest we do assessments quarterly to see if we should do a minor bump.

v0.10 and v0.12 are still, by far, the most broadly used node.js versions. While there are lots of great things happening in the io.js stream, it would be a very good idea to continue LTS support on v0.10 and v0.12 as well as continue to cut new LTS releases on the v0.x stream for the foreseeable future -- so long as we have collaborators actively willing to support that stream. This would ensure that those users/customers who are not quite ready to make the jump up will continue to be supported.

The net result is that at some point this year, we should likely expect a v0.14 LTS cut off the joyent/node stream before end of year.

/cc @nodejs/tsc

See https://github.com/nodejs/LTS/#proposed-lts for the current proposal and leave feedback here. This is effectively a continuation of #8 but we now have a concrete proposal.