You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are planning monthly releases on the first Tuesday of every month for v4 and v6, and a single v0.12 release in the first week of December. Currently our only planned Semver-Minor release if v4.7.0 on December 6th, but it is possible that one of the patch releases on v4 or v6 could be a minor release if deemed necessary by the LTS Working Group. These dates are also subject to change based on the need for security releases.
Please let me know if you have problems with the dates above. I would also be interested if individuals think the information above could be presented in a clearer fashion. I'm also interested if individuals think that the above information should be present in the repo's readme.
@AdriVanHoudt that might give the impression that these dates are more concrete than they are, there's a bunch of factors that could easily change these plans, most notably security releases which could change version numbers and bump dates if they are too close.
@rvagg good point, it was just my initial thought on could be presented in a clearer fashion but you are right if they are not final it probably just a case of where to put the info
On Wed, Dec 7, 2016, 12:55 PM Hutson Betts ***@***.***> wrote:
I agree with @rvagg <https://github.com/rvagg> that the information
should not be coupled with the LTS release schedule.
I do think the schedule should be posted to the README. A comment, in the
form of a quote, above the schedule would be fine for the purpose of
educating the community that the release schedule should be considered
"best effort", but is subject to change.
Posting the schedule to the README, in my opinion, makes the schedule,
and the best intentions of the LTS group, feel more *legit* than an issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#159 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV23bl-2DN36ZywScluv2parcBH3uks5rFx1bgaJpZM4K0n3X>
.
In that case, I find the formatting of the dates in the original issue comment to be readable, and this issue to be sufficient; with the caveat that it would be helpful if the issue's original comment is kept up-to-date (so that I do not need to parse the entire thread to grasp the current state of your release plans).
On Wed, Dec 7, 2016, 8:00 PM Hutson Betts ***@***.***> wrote:
In that case, I find the formatting of the dates in the original issue
comment to be readable, and this issue to be sufficient; with the caveat
that it would be helpful if the issue's original comment is kept up-to-date
(so that I do not need to parse the entire thread to grasp the current
state of your release plans).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#159 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV43p0roHwHzNCYoibd63LlR574Knks5rF4DdgaJpZM4K0n3X>
.
@mhdawson based on the schedule v4 is moving to maintenance mode as of April 1st. We just did a semver minor last month, so I think it is a bit soon to do the minor for v6.
I'll put together a new issue for our Q2 release schedule next week
Activity
MylesBorins commentedon Nov 16, 2016
Please let me know if you have problems with the dates above. I would also be interested if individuals think the information above could be presented in a clearer fashion. I'm also interested if individuals think that the above information should be present in the repo's readme.
AdriVanHoudt commentedon Nov 18, 2016
Can it be visualised on the current (most used?) LTS visualisation from Nodesource?
rvagg commentedon Nov 19, 2016
@AdriVanHoudt that might give the impression that these dates are more concrete than they are, there's a bunch of factors that could easily change these plans, most notably security releases which could change version numbers and bump dates if they are too close.
AdriVanHoudt commentedon Nov 19, 2016
@rvagg good point, it was just my initial thought on
could be presented in a clearer fashionbut you are right if they are not final it probably just a case of where to put the infoMylesBorins commentedon Dec 7, 2016
hutson commentedon Dec 8, 2016
In that case, I find the formatting of the dates in the original issue comment to be readable, and this issue to be sufficient; with the caveat that it would be helpful if the issue's original comment is kept up-to-date (so that I do not need to parse the entire thread to grasp the current state of your release plans).
MylesBorins commentedon Dec 8, 2016
richardlau commentedon Jan 5, 2017
@MylesBorins Maybe update the first comment to take into account the point releases made earlier today?
[-]Release plan for v0.12 / v4 / v6 until April 2017[/-][+]Release plan for v4 / v6 until April 2017[/+]MylesBorins commentedon Jan 6, 2017
@richardlau good call!
mhdawson commentedon Mar 14, 2017
@MylesBorins should we be adding the schedule for the next 2 releases as well ? Possibly:
April 24th
Release of v4.9 (as Quarterly semver minor starting off Maintenance phase) and v6.11
May 23rd
Release v6.11.1
MylesBorins commentedon Mar 14, 2017
@mhdawson based on the schedule v4 is moving to maintenance mode as of April 1st. We just did a semver minor last month, so I think it is a bit soon to do the minor for v6.
I'll put together a new issue for our Q2 release schedule next week