RELEASES: define the release process#1310
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1310 +/- ##
=======================================
Coverage 35.56% 35.56%
=======================================
Files 23 23
Lines 2874 2874
=======================================
Hits 1022 1022
Misses 1627 1627
Partials 225 225Continue to review full report at Codecov.
|
samuelkarp
left a comment
There was a problem hiding this comment.
Thank you for sending this out! It's great to see these policies emerge.
There was a problem hiding this comment.
Can we add a section defining exactly what is meant by "backwards compatibility" here? It looks like this paragraph is meant to allow some sort of deprecation policy, and it'd be good to understand what kinds of things might change.
There was a problem hiding this comment.
Would this make more sense without the work "backwards" here?
There was a problem hiding this comment.
Give the new wording a try.
There was a problem hiding this comment.
Is the 1 year support period a hard limit or just a minimum?
There was a problem hiding this comment.
I would say a minimum. If we actually get help from the community backporting patches then it makes support much easier. That hasn't been the case in the past and things are left up to the maintainers for support, new features, reviews, and backports. If everyone carries the load it makes it much easier to support long term.
There was a problem hiding this comment.
I assume this means "next minor or major"?
There was a problem hiding this comment.
There should be an explicit contact mechanism for security issues rather than just asking the reporter to be discreet.
There was a problem hiding this comment.
We will have to setup a security mailing list for these things.
There was a problem hiding this comment.
It would also be desirable to have a documented GPG key (or multiple keys, if for individuals) with which sensitive issues can be protected. Some details about how security issues will be handled will also help. (e.g. how quickly will somebody acknowledge receipt of a report? Will non-public information be shared with other distributors prior to publication? etc) ISC has a rather comprehensive example of a security policy, split across two pages. I wouldn't necessarily suggest going that far, but it's worth reading.
There was a problem hiding this comment.
I think it's worth calling out somewhere that because the GRPC API is covered by the stability guarantee, applications built against the 1.0 Go API will continue to work with the same versions that the stable GRPC API will, as the Go API leverages the GRPC API.
There was a problem hiding this comment.
Added a note about this in the "Go API" section.
There was a problem hiding this comment.
What else can be added in a minor release? Would a minor release also allow the addition of service calls, parameters, and return elements?
There was a problem hiding this comment.
Is this about microformats or really just about opaque fields?
There was a problem hiding this comment.
It would be valuable to a client if there were a list of explicitly opaque fields.
There was a problem hiding this comment.
Right now, all fields should be treated opaquely.
There was a problem hiding this comment.
Also, we should defer to the service proto for these considerations.
There was a problem hiding this comment.
I think you mean non-exhaustive? Or it might be easier to phrase it as: This explicitly pertains to, but is not limited to, the list of components below.
There was a problem hiding this comment.
currently recommended -> recommended ?
Even after API stabilization, vendoring would be preferred in Go world.
There was a problem hiding this comment.
What does it stand for? Layout of /var/lib/containerd and /run/containerd?
There was a problem hiding this comment.
Migration is done automatically for upgrade from single previous minor release, right?
There was a problem hiding this comment.
I guess this section is mainly about the client library.
Does it apply for plugins as well?
There was a problem hiding this comment.
Binary compatibility of plugin DLLs?
There was a problem hiding this comment.
This does not exist at the moment
There was a problem hiding this comment.
Agreed.
So, I meant it would be good to add plugin ABI to this "Not Covered" list.
There was a problem hiding this comment.
@AkihiroSuda The plugin ABI is not part of the project, since we are supporting them for now.
There was a problem hiding this comment.
It would be good to reference the fingerprint of the signing key(s) here (and more generally to get it into the WoT or at least widely distributed).
There was a problem hiding this comment.
Right now, we don't really want to make a single signing key. I'll use https://keybase.io/stevvooe.
There was a problem hiding this comment.
"within" is one word in this context I think,
There was a problem hiding this comment.
The phrase "from two minor releases" is difficult to grok I think perhaps "upgrades spanning multiple minor releases"?.
Also I think it's either "There are no compatibility guarantees" or "There is no compatibility guarantee" rather than "There is no compatibility guarantees".
There was a problem hiding this comment.
By my reading of the preceding paragraphs EOL for 1.0 is actually max(TBD+1 year, release of 1.1.0)?
1f76331 to
92eb624
Compare
|
This is Cool! LGTM overall. |
|
LGTM |
|
Can we have a section listing the state of "stableness" for the plugins? For instance, if we were to release today, the |
|
@mlaventure Do you mind if we do this in a follow up? |
|
Follow SGTM. LGTM |
There was a problem hiding this comment.
typo: I think you're missing a word between "a" and "minor"
There was a problem hiding this comment.
You may want to consider some (brief) period of overlap in support in case issues arise in the upgrade path between minor versions that are best addressed with patches to the previous (otherwise unsupported) release. Or maybe just call out the possibility that exceptions can be made in situations that interfere with a clean upgrade.
There was a problem hiding this comment.
Would it be fine if we made this table the source of truth, over the policy?
There was a problem hiding this comment.
It would also be desirable to have a documented GPG key (or multiple keys, if for individuals) with which sensitive issues can be protected. Some details about how security issues will be handled will also help. (e.g. how quickly will somebody acknowledge receipt of a report? Will non-public information be shared with other distributors prior to publication? etc) ISC has a rather comprehensive example of a security policy, split across two pages. I wouldn't necessarily suggest going that far, but it's worth reading.
There was a problem hiding this comment.
typo: another missing word, between "overview" and "the".
|
@nmeyerhans The security reporting issue and GPG issues have already been discussed. I've filed #1337 to cover the security escalation process, which is blocking on a proper mailing list and embargo list. My key is in github. Releases can be verified against the account. There are no plans to have a central key. |
Define the release process for containerd and outline the components that are and are not covered by versioning guarantees. Please read the document for details. Signed-off-by: Stephen J Day <[email protected]>
|
LGTM |
Define the release process for containerd and outline the components
that are and are not covered by versioning guarantees. Please read the
document for details.
Signed-off-by: Stephen J Day [email protected]