New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RELEASES.md: update release status #4059
RELEASES.md: update release status #4059
Conversation
Build succeeded.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Codecov Report
@@ Coverage Diff @@
## master #4059 +/- ##
==========================================
- Coverage 42.67% 42.53% -0.15%
==========================================
Files 130 130
Lines 14778 14828 +50
==========================================
Hits 6307 6307
- Misses 7552 7602 +50
Partials 919 919
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I believe we want a quorum of maintainers to LGTM this as it changes support timeframes for a release? ping @containerd/containerd-maintainers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I suggest we keep the EOL date as is AND use the Extended option to support security updates through October. Why: k8s support is only latest and the last two (n-2) minor versions (just 6-9months) only exception is for some CVEs. Our response, so far, was to move up our support for k8s from k8s v1.12 to v1.14 and to support CVEs. See tables here https://github.com/containerd/cri#support-metrics Kubernetes is about to release 1.18, ... needless to say the model of punting our EOL down the road is problematic because of CRI's reliance on k8s support. |
Thanks! @mikebrow . Your suggestion LGTM. And I will update the pr with the following changes after March 26.
And do we need to put the start date for extended status? because the |
I was thinking we'd keep the end of life date unchanged and add a new date column for extended (past EOL) support entering N/A for the other releases. @dmcgowan @estesp thoughts? |
When we extended 1.1 it looked like
I think we could probably split the time to |
SGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
1. Update release status 2. Add Extended state for release v1.2 Signed-off-by: Wei Fu <fuweid89@gmail.com>
c9deb2c
to
8c9e841
Compare
Build succeeded.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ping @dmcgowan and maybe @crosbymichael before we merge--looks like all active comments have been taken into account. |
LGTM |
Signed-off-by: Wei Fu fuweid89@gmail.com