diff --git a/layouts/about-release-schedule.hbs b/layouts/about-release-schedule.hbs new file mode 100644 index 0000000000000..f4a1e657aaf77 --- /dev/null +++ b/layouts/about-release-schedule.hbs @@ -0,0 +1,35 @@ + + +{{> html-head }} + + + {{> header }} + +
+
+ + {{> navigation key='about'}} + +
+

{{ title }}

+ +

+ {{ title }} +

+ + {{{ release-schedule }}} + +

+ {{ schedule-footer }} +

+ + + {{{ contents }}} +
+ +
+
+ + {{> footer }} + + diff --git a/layouts/css/page-modules/_release-schedule.styl b/layouts/css/page-modules/_release-schedule.styl new file mode 100644 index 0000000000000..07f4239cd6892 --- /dev/null +++ b/layouts/css/page-modules/_release-schedule.styl @@ -0,0 +1,20 @@ +table.release-schedule + width 100% + font-size 1rem + border 1px solid $light-gray2 + + td + padding 5px + + > thead + font-weight 600 + text-align left + + > tbody + border-top 1px solid $light-gray2 + + tr:nth-child(odd) + background-color $light-gray3 + + tr:nth-child(even) + background-color $white diff --git a/layouts/css/styles.styl b/layouts/css/styles.styl index 4152bf149b577..022e989f411f7 100644 --- a/layouts/css/styles.styl +++ b/layouts/css/styles.styl @@ -17,6 +17,7 @@ @import 'page-modules/_scrollToTop' @import 'page-modules/_anchorLinks' @import 'page-modules/_prev-next-navigation' +@import 'page-modules/_release-schedule' .intro margin-top 140px diff --git a/locale/en/about/releases.md b/locale/en/about/releases.md index 2028456e8c100..63da6d2e9c1c9 100644 --- a/locale/en/about/releases.md +++ b/locale/en/about/releases.md @@ -1,86 +1,18 @@ --- -layout: about.hbs +layout: about-release-schedule.hbs title: Releases +statuses: + maintenance: 'Maintenance LTS' + active: 'Active LTS' + current: 'Current' + pending: 'Pending' +columns: + - 'Release' + - 'Status' + - 'Codename' + - 'Initial Release' + - 'Active LTS Start' + - 'Maintenance LTS Start' + - 'End-of-life' +schedule-footer: Dates are subject to change. --- -# Releases - -The core team defines the roadmap's scope, as informed by Node.js' community. -Releases happen as often as necessary and practical, but never before work is -complete. Bugs are unavoidable, but pressure to ship a release will never -prevail over ensuring the software is correct. The commitment to quality -software is a core tenet of the Node.js project. - -## Patches - -Patch releases: - -- Include bug, performance, and security fixes. -- Do not add nor change public interfaces. -- Do not alter the expected behavior of a given interface. -- Can correct behavior if it is out-of-sync with the documentation. -- Do not introduce changes which make seamless upgrades impossible. - -## Minors - -Minor releases: - -- Include additions and/or refinements of APIs and subsystems. -- Do not generally change APIs nor introduce backwards-incompatible breaking -changes, except where unavoidable. -- Are mostly additive releases. - -## Majors - -Major releases: - -- Usually introduce backwards-incompatible, breaking changes. -- Identify the API Node.js intends to support for the foreseeable future. -- Require conversation, care, collaboration and appropriate scoping by the team -and its users. - -## Scoping Features - -The team can add features and APIs into Node.js when: - -- The need is clear. -- The API or feature has known consumers. -- The API is clean, useful, and easy-to use. - -If when implementing core functionality for Node.js, the team or community may -identify another lower-level API which could have utility beyond Node.js. When -identified, Node.js can expose it for consumers. - -For example, consider the [`EventEmitter`] interface. The need to have an event -subscription model for core modules to consume was clear, and that abstraction -had utility beyond the Node.js core. It was not the case that its interface -couldn't be implemented externally to Node.js; instead, Node.js needed the -abstraction for itself, and also exposed it for use by Node.js consumers. - -Alternatively, it may be that many in the community adopt a pattern to handle -common needs which Node.js does not satisfy. It may be clear that Node.js -should deliver, by default, an API or feature for all Node.js consumers. -Another possibility is a commonly-used compiled asset which is difficult to -deliver across environments. Given this, Node.js may incorporate those changes -directly. - -The core team does not take the decision lightly to add a new API to Node.js. -Node.js has a strong commitment to backwards compatibility. As such, community -input and conversation must occur before the team takes action. Even if an API -is otherwise suitable for addition, the team must identify potential consumers. - -## Deprecation - -On occasion, the team must deprecate a feature or API of Node.js. Before coming -to any final conclusion, the team must identify the consumers of the API and how -they use it. Some questions to ask are: - -- If this API is widely used by the community, what is the need for flagging it -as deprecated? -- Do we have a replacement API, or is there a transitionary path? -- How long does the API remain deprecated before removal? -- Does an external module exist which its consumers can easily substitute? - -The team takes the same careful consideration when deprecating a Node.js API as -they do when adding another. - -[`EventEmitter`]: https://nodejs.org/api/events.html#events_class_eventemitter diff --git a/locale/fa/about/releases.md b/locale/fa/about/releases.md index 2028456e8c100..63da6d2e9c1c9 100644 --- a/locale/fa/about/releases.md +++ b/locale/fa/about/releases.md @@ -1,86 +1,18 @@ --- -layout: about.hbs +layout: about-release-schedule.hbs title: Releases +statuses: + maintenance: 'Maintenance LTS' + active: 'Active LTS' + current: 'Current' + pending: 'Pending' +columns: + - 'Release' + - 'Status' + - 'Codename' + - 'Initial Release' + - 'Active LTS Start' + - 'Maintenance LTS Start' + - 'End-of-life' +schedule-footer: Dates are subject to change. --- -# Releases - -The core team defines the roadmap's scope, as informed by Node.js' community. -Releases happen as often as necessary and practical, but never before work is -complete. Bugs are unavoidable, but pressure to ship a release will never -prevail over ensuring the software is correct. The commitment to quality -software is a core tenet of the Node.js project. - -## Patches - -Patch releases: - -- Include bug, performance, and security fixes. -- Do not add nor change public interfaces. -- Do not alter the expected behavior of a given interface. -- Can correct behavior if it is out-of-sync with the documentation. -- Do not introduce changes which make seamless upgrades impossible. - -## Minors - -Minor releases: - -- Include additions and/or refinements of APIs and subsystems. -- Do not generally change APIs nor introduce backwards-incompatible breaking -changes, except where unavoidable. -- Are mostly additive releases. - -## Majors - -Major releases: - -- Usually introduce backwards-incompatible, breaking changes. -- Identify the API Node.js intends to support for the foreseeable future. -- Require conversation, care, collaboration and appropriate scoping by the team -and its users. - -## Scoping Features - -The team can add features and APIs into Node.js when: - -- The need is clear. -- The API or feature has known consumers. -- The API is clean, useful, and easy-to use. - -If when implementing core functionality for Node.js, the team or community may -identify another lower-level API which could have utility beyond Node.js. When -identified, Node.js can expose it for consumers. - -For example, consider the [`EventEmitter`] interface. The need to have an event -subscription model for core modules to consume was clear, and that abstraction -had utility beyond the Node.js core. It was not the case that its interface -couldn't be implemented externally to Node.js; instead, Node.js needed the -abstraction for itself, and also exposed it for use by Node.js consumers. - -Alternatively, it may be that many in the community adopt a pattern to handle -common needs which Node.js does not satisfy. It may be clear that Node.js -should deliver, by default, an API or feature for all Node.js consumers. -Another possibility is a commonly-used compiled asset which is difficult to -deliver across environments. Given this, Node.js may incorporate those changes -directly. - -The core team does not take the decision lightly to add a new API to Node.js. -Node.js has a strong commitment to backwards compatibility. As such, community -input and conversation must occur before the team takes action. Even if an API -is otherwise suitable for addition, the team must identify potential consumers. - -## Deprecation - -On occasion, the team must deprecate a feature or API of Node.js. Before coming -to any final conclusion, the team must identify the consumers of the API and how -they use it. Some questions to ask are: - -- If this API is widely used by the community, what is the need for flagging it -as deprecated? -- Do we have a replacement API, or is there a transitionary path? -- How long does the API remain deprecated before removal? -- Does an external module exist which its consumers can easily substitute? - -The team takes the same careful consideration when deprecating a Node.js API as -they do when adding another. - -[`EventEmitter`]: https://nodejs.org/api/events.html#events_class_eventemitter diff --git a/locale/ko/about/releases.md b/locale/ko/about/releases.md index 83ee387d6e19a..e04fefc8f13da 100644 --- a/locale/ko/about/releases.md +++ b/locale/ko/about/releases.md @@ -1,167 +1,18 @@ --- -layout: about.hbs +layout: about-release-schedule.hbs title: 릴리스 +statuses: + maintenance: '유지보수 LTS' + active: '활성 LTS' + current: '현재 버전' + pending: '대기 중' +columns: + - '릴리스' + - '상태' + - '코드네임' + - '최초 릴리스' + - '활성 LTS 시작' + - '유지보수 LTS 시작' + - '지원 종료' +schedule-footer: 날짜는 변경될 수 있습니다. --- - -# 릴리스 - -Node.js 커뮤니티가 알고 있듯이 코어 팀은 로드맵의 범위를 정의합니다. 필요하고 실용적이라면 최대한 -자주 릴리스를 하지만 작업이 완료되지 않으면 하지 않습니다. 버그는 보이지 않을 수 있지만, 릴리스에 대한 -압박은 소프트웨어가 제대로 되었다고 확신을 넘어설 수 없습니다. -소프트웨어의 질에 대한 책임은 Node.js 프로젝트의 핵심 신조입니다. - - - -## 패치 - -패치 릴리스는 - -- 버그, 성능, 보안 수정을 포함합니다. -- 공개 인터페이스를 추가하거나 변경하지 않습니다. -- 제공한 인터페이스에서 기대되는 동작을 변경하지 않습니다. -- 문서와 일치하지 않다면 제대로 동작하도록 할 수 있습니다. -- 자연스럽게 업그레이드할 수 없는 변경사항을 추가하지 않습니다. - - - -## 마이너 - -마이너 릴리스는 - -- API와 서브시스템의 추가나 개선을 포함합니다. -- 보통 API를 변경하지 않고 불가피하지 않은 경우를 제외하고는 하위호환성을 깨뜨리는 변경사항을 추가하지 않습니다. -- 대부분 부가적인 릴리스입니다. - - - -## 메이저 - -메이저 릴리스는 - -- 보통 하위호환성을 깨뜨리는 변경사항을 추가합니다. -- Node.js가 예견할 수 있는 미래를 준비할 수 있도록 API를 식별합니다. -- 코어 팀과 사용자들의 대화, 관심, 협업, 적당한 범위 설정이 필요합니다. - - - -## 기능의 범위 정하기 - -코어 팀은 다음에서 Node.js에 기능이나 API를 추가할 수 있습니다. - -- 요구사항이 확실할 때 -- API나 기능이 알려진 사용자를 가질 때 -- API가 깔끔하고 유용하면서 사용하기 쉬울 때 - - -예를 들어, [`EventEmitter`] 인터페이스를 생각해 보겠습니다. 코어 모듈에서 사용할 수 있는 -이벤트 구독 모델이 필요하다는 것은 했고 이 추상화는 Node.js 코어의 범위를 벗어나는 유틸리티를 가집니다. -이는 이 추상화의 인터페이스가 Node.js 외부에서 구현될 수 없는 경우가 아닙니다. 오히려 Node.js가 -직접 추상화할 필요가 있었고 Node.js 사용자가 사용할 수 있도록 이를 노출해야 했습니다. - -아니면 Node.js가 만족하게 하지 못하는 일반적인 요구사항을 해결하는 패턴을 커뮤니티의 다수가 도입할 -수도 있습니다. Node.js가 모든 Node.js 사용자를 위한 API나 기능을 기본적으로 제공하는 것이 -더 명확할 수도 있습니다. 여러 환경을 지원하기 어렵지만, 일반적으로 사용되는 에셋을 컴파일해서 제공하는 -것도 가능합니다. 이러한 상황을 고려하면 Node.js가 직접 이러한 변경사항을 받아들여야 할 수도 있습니다. - -코어 팀은 새로운 API를 Node.js에 추가할 때 가볍게 결정하지 않습니다. Node.js는 하위호환성을 -지원해야 하는 큰 의무가 있습니다. 그래서 코어 팀이 행동을 취하기 전에 커뮤니티의 요청이나 토론이 -반드시 먼저 일어나게 됩니다. API를 추가하는 것이 적합한 경우조차도 코어 팀은 잠재적인 사용자를 -확인해야 합니다. - - - -## 폐기 예정 - -때때로 코어 팀은 Node.js의 기능이나 API를 폐기해야 합니다. 최종 결정을 하기 전에 코어 팀은 API의 사용자와 이들이 그 API를 어떻게 사용하고 있는지를 반드시 확인해야 합니다. 이때 다음과 같은 질문을 해봐야 합니다. - -- 커뮤니티에서 이 API를 광범위하게 사용하고 있다면 폐기 예정으로 표시하는 데 필요한 일은 어떤 것인가? -- 대체 API가 있는가? 아니면 과도기적인 경로가 존재하는가? -- API를 제거하기 전에 폐기 예정을 얼마나 오랫동안 유지해야 하는가? -- 그 API의 사용자가 쉽게 대체할 수 있는 외부 모듈이 존재하는가? - -코어 팀은 Node.js API를 폐기할 때 API를 추가할 때와 마찬가지로 신중하게 고려합니다. - -[`EventEmitter`]: https://nodejs.org/api/events.html#events_class_eventemitter diff --git a/locale/uk/about/releases.md b/locale/uk/about/releases.md index 84409b7bc5576..ff7c4a7127f60 100644 --- a/locale/uk/about/releases.md +++ b/locale/uk/about/releases.md @@ -1,81 +1,18 @@ --- -layout: about.hbs +layout: about-release-schedule.hbs title: Релізи +statuses: + maintenance: 'Підтримуваний LTS' + active: 'Активний LTS' + current: 'Поточний' + pending: 'Майбутній' +columns: + - 'Резіз' + - 'Статус' + - 'Кодова назва' + - 'Початковий реліз' + - 'Початок активного LTS' + - 'Початок підтримуваного LTS' + - 'Кінець підтримки' +schedule-footer: Дати можуть змінитись. --- -# Релізи - -Основна команда визначила дорожню карту, з якою знайома спільнота Node.js. -Релізи відбуваються так часто, наскільки це необхідно і практично, проте не -раніше, ніж роботу буде закінчено. -Багів не уникнути, проте випуск релізів переважати преред впевненістю щодо коректної роботи програмного забезпечення. Високі стандарти якості є одним з -ключових пріоритетів проекту Node.js. - -## Патчі - -Патч–релізи: - -- включають виправлення багів, покращення безпеки та швидкодії; -- не додають і не змінюють публічних інтерфейсів; -- не змінюють очікуваної поведінки даного інтерфейсу; -- можуть виправляти поведінку, якщо вона не вказана в документації; -- не вносять зміни, які унеможливлюють безшовні оновлення. - -## Мінори - -Мінорні релізи: - -- включають доповнення, або розширення API та підсистем; -- загалом не змінюють API і не вводять зміни, що ламають зворотну сумісність, окрім тих, які неможливо уникнути; -- є, здебільшого, доповнюючими релізами. - -## Мажори - -Мажорні релізи: - -- зазвичай вводять зміни, що ламають зворотну сумісність; -- визначають API Node.js для підтримки у найближчому майбутньому; -- вимагають обговорень, обережності, співправці між командою та користувачами. - -## Оцінка функціональності - -Команда може додавати новий функціонал та APІ у Node.js якщо: - -- зрозумілі потреби; -- API або функціонал має відомих споживачів; -- API є чистим, корисним та зручним для використання. - -При реалізації функціональних можливостей ядра Node.js, команда або спільнота -може визначити інший API нижчого рівня, які могли б бути корисні поза Node.js. -Після визначення Node.js може виставити його для споживачів. - -Наприклад, розглянемо інтерфейс [`EventEmitter`]. Потреба мати модель для підписки на події у модулях ядра є зрозумілою і ця абстракція може використовуватись поза ядром Node.js. Це не той випадок, коли інтерфейс не може бути реалізований поза Node.js, навпаки Node.js потребує цієї абстракції для себе і відкриває її для користувачів Node.js. - -Окрім того, може бути таке, що частина спільноти прийме шаблон -для обробки деяких загальних потреб, який не задовільнятиме Node.js. -Зрозуміло, що Node.js має за замовчуванням постачати API -та функціонал для всіх користувачів Node.js. -Інший можливий випадок полягає у додаткових скомпільованих розширеннях, -які важко поширювати на різних оточеннях. З огляду на це, -Node.js може включати ці зміни безпосередньо. - -Основна команда не приймає легковажно рішення стосовно внесення -нового API у Node.js. Node.js надає зворотній сумісності високого пріоритету. -Таким чином, спільнота має прийняти та обговорити зміни перед тим, -як команда прийматиме ці зміни. Навіть якщо API добре підходить змінам, -команда мусить визначити потенційних споживачів. - -## Визначення застарілості - -У деяких випадках команда мусить визнати деякий функціонал та API -в Node.js застарілими. Перед прийняттям будь–якого остаточного рішення, -команда мусить визначити користувачів API і те, -як вони його використовують. Ось деякі запитання до них: - -- Якщо це API широко використовується спільнотою, чому ми маємо визначати його застарілим? -- Чи маємо ми API для заміни, чи зрозумілим є шлях переходу? -- Як довго API має залишатись застарілим перед видаленням? -- Чи існує якийсь зовнішній модуль, яким можна легко його замінити? - -Команда має проявляти таку ж обережність при визначенні APІ застарілим, як і при додаванні нового APІ в Node.js API. - -[`EventEmitter`]: https://nodejs.org/api/events.html#events_class_eventemitter diff --git a/locale/zh-cn/about/releases.md b/locale/zh-cn/about/releases.md index 204b54de92cf1..7da66856aa1b1 100644 --- a/locale/zh-cn/about/releases.md +++ b/locale/zh-cn/about/releases.md @@ -1,62 +1,18 @@ --- -layout: about.hbs +layout: about-release-schedule.hbs title: 发布 +statuses: + maintenance: '长期维护版' + active: '长期支持版（主推）' + current: '当前版' + pending: '待定' +columns: + - '发布' + - '状态' + - '代号' + - '首发日' + - '长期支持版（主推）开始日期' + - '长期维护版开始日期' + - '（服务）终止日期' +schedule-footer: 日期可能会发生变化。 --- -# 发布 - -核心团队根据 Nodejs 社区的通知定义了路线图。项目发布是经常且必要的和实际的，但不会在任务完成前发布；缺陷是不可避免的，但发布释放的压力将永远不会确保软件是正确的。对质量软件的承诺是 Node.js 核心项目的宗旨。 - -## 补丁 - -补丁发布： - -- 包含缺陷、性能以及安全修复。 -- 请勿添加或者改变任何公共接口。 -- 请勿改变已有接口的行为。 -- 如果已有接口与文档不同步了，可以改变其行为。 -- 请勿引入修改，使得无缝升级变得不可能。 - -## 中等发布 - -中等发布： - -- 包括 API 和 子系统的新增以及改进。 -- 通常不更改 API，也不引入向后不兼容的中断更改，除非不可避免。 -- 大多是（功能）性增加。 - -## 主要发布 - -主版本发布： - -- 通常引入向后不兼容的、中断的更改。 -- 标识 Node.js 的 API，它们打算在可预见的未来得到支持。 -- 需要团队及其用户的对话、关心、协作和适当的范围。 - -## 作用域功能 - -在以下情况下团队可以添加新功能以及新的 API： - -- 需求是清晰的。 -- API 或 特性对于客户是已知的。 -- API 清爽、实用且易于使用。 - -如果在实现 Node 的核心功能时，团队或社区可能会识别另一个较低级别的 API，这可能会超出 Node.js 的效用。在确定之后，Node.js 可以向消费者公开它。 - -例如，考虑 [`EventEmitter`] 接口。 需要为核心模块使用一个事件订阅模型是清楚的，而且此接口的抽象所拥有的实质意义远高于 Node.js 核心；但事实并非如此，接口无法透过外部对 Node.js 进行实现，相应地，Node.js 自身需要该抽象，而且把它暴漏给公共人员使用。 - -另外，也可能是社区中的许多人采用一种模式，但 Node.js 对此并不满意。而 Node.js 对公共消费者发布一个很清晰的 API 或是新特性；另一种可能性是通常使用的编译内容很难跨环境传递。鉴于此，Node.js 可以直接合并这些更改。 - -到底是否将一个新的 API 添加到 Node.js中，核心团队不会轻易做出决定。因为 Node.js 对向后兼容性有很强的承诺。因此在团队采取行动之前，社区投入和对话必须发生。即使 API 在其它方面也适合添加，团队也必须识别潜在的消费者。 - -## 废弃声明 - -有时，团队必须把某个 Node.js 的函数废弃；在得出最终结论之前，团队必须确定 API 的使用者以及他们如何利用它。有些问题要问: - -- 如果此 API 被社区广泛使用，那么有什么必要将其标记为已否决？ -- 我们有替代 API，还是有过渡方式？ -- 在删除之前，API 需要“废弃”多久？ -- 外部模块是否存在，消费者可以使用之轻松地替代？ - -如新添一个 API 一样，在对 Node.js 进行废弃操作时，团队需要进行同样的仔细考虑废弃操作的后果。 - -[`EventEmitter`]: https://nodejs.org/api/events.html#events_class_eventemitter diff --git a/package.json b/package.json index 501fc3f67101b..d18f3049c3f34 100644 --- a/package.json +++ b/package.json @@ -8,8 +8,9 @@ "serve": "node server.js", "external:survey": "rsync -avz --exclude 'node_modules*' --exclude 'package*' external/survey-2018/ build/en/user-survey-report", "gzip": "find build -type f \\( -name '*.html' -o -name '*.css' -o -name '*.js' -o -name '*.xml' -o -name '*.json' \\) -exec gzip -kf9 {} \\;", - "deploy": "npm run build && npm run external:survey && npm run gzip", + "deploy": "npm run load-schedule && npm run build && npm run external:survey && npm run gzip", "load-versions": "node scripts/load-versions.js", + "load-schedule": "curl -sS https://raw.githubusercontent.com/nodejs/Release/master/schedule.json -o source/schedule.json", "start": "npm run serve", "test": "npm run test:lint && npm run test:unit && npm run test:smoke", "test:lint": "standard && htmllint **/*.hbs && stylint layouts/css", diff --git a/scripts/helpers/release-schedule.js b/scripts/helpers/release-schedule.js new file mode 100644 index 0000000000000..6e1f021bca2a9 --- /dev/null +++ b/scripts/helpers/release-schedule.js @@ -0,0 +1,62 @@ +'use strict' + +const schedule = require('../../source/schedule.json') + +const today = new Date() +const datify = (release, key) => new Date(schedule[release][key]) + +module.exports = context => { + const statuses = context.data.root.statuses + + const header = context.data.root.columns + .map(column => `${column}\n`) + .join('') + + let content = '' + + Object.keys(schedule) + .filter(release => datify(release, 'end') > today) + .forEach(release => { + const codename = schedule[release].codename + const codenameLink = codename + ? `${codename}` + : '' + + const releaseLink = datify(release, 'start') < today + ? `${release}` + : release + + let status + + if (datify(release, 'start') > today) { + status = statuses.pending + } else if (!schedule[release].lts || datify(release, 'lts') > today) { + status = statuses.current + } else if (datify(release, 'maintenance') < today) { + status = statuses.maintenance + } else if (datify(release, 'lts') < today) { + status = statuses.active + } + + content += ` + ${releaseLink} + ${status} + ${codenameLink} + ${schedule[release].start || ''} + ${schedule[release].lts || ''} + ${schedule[release].maintenance || ''} + ${schedule[release].end || ''} + ` + }) + + return ` + + + ${header} + + + ${content} + +
+ ` +} diff --git a/source/schedule.json b/source/schedule.json new file mode 100644 index 0000000000000..3eda10b8889eb --- /dev/null +++ b/source/schedule.json @@ -0,0 +1,65 @@ +{ + "v0.10": { + "start": "2013-03-11", + "end": "2016-10-31" + }, + "v0.12": { + "start": "2015-02-06", + "end": "2016-12-31" + }, + "v4": { + "start": "2015-09-08", + "lts": "2015-10-12", + "maintenance": "2017-04-01", + "end": "2018-04-30", + "codename": "Argon" + }, + "v5": { + "start": "2015-10-29", + "maintenance": "2016-04-30", + "end": "2016-06-30" + }, + "v6": { + "start": "2016-04-26", + "lts": "2016-10-18", + "maintenance": "2018-04-30", + "end": "2019-04-01", + "codename": "Boron" + }, + "v7": { + "start": "2016-10-25", + "maintenance": "2017-04-30", + "end": "2017-06-30" + }, + "v8": { + "start": "2017-05-30", + "lts": "2017-10-31", + "maintenance": "2019-04-01", + "end": "2019-12-31", + "codename": "Carbon" + }, + "v9": { + "start": "2017-10-01", + "maintenance": "2018-04-01", + "end": "2018-06-30" + }, + "v10": { + "start": "2018-04-24", + "lts": "2018-10-30", + "maintenance": "2020-04-01", + "end": "2021-04-01", + "codename": "Dubnium" + }, + "v11": { + "start": "2018-10-23", + "maintenance": "2019-04-01", + "end": "2019-06-30" + }, + "v12": { + "start": "2019-04-23", + "lts": "2019-10-22", + "maintenance": "2021-04-01", + "end": "2022-04-01", + "codename": "" + } +}