Skip to content

RELEASES: define the release process#1310

Merged
crosbymichael merged 1 commit intocontainerd:masterfrom
stevvooe:releases
Aug 11, 2017
Merged

RELEASES: define the release process#1310
crosbymichael merged 1 commit intocontainerd:masterfrom
stevvooe:releases

Conversation

@stevvooe
Copy link
Copy Markdown
Member

@stevvooe stevvooe commented Aug 8, 2017

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]

@codecov-io
Copy link
Copy Markdown

codecov-io commented Aug 8, 2017

Codecov Report

Merging #1310 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #1310   +/-   ##
=======================================
  Coverage   35.56%   35.56%           
=======================================
  Files          23       23           
  Lines        2874     2874           
=======================================
  Hits         1022     1022           
  Misses       1627     1627           
  Partials      225      225

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 56d499e...9827b4c. Read the comment docs.

Copy link
Copy Markdown
Member

@samuelkarp samuelkarp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for sending this out! It's great to see these policies emerge.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this make more sense without the work "backwards" here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Give the new wording a try.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the 1 year support period a hard limit or just a minimum?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding at least here.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this means "next minor or major"?

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be an explicit contact mechanism for security issues rather than just asking the reporter to be discreet.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will have to setup a security mailing list for these things.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

@stevvooe stevvooe Aug 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a note about this in the "Go API" section.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What else can be added in a minor release? Would a minor release also allow the addition of service calls, parameters, and return elements?

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this about microformats or really just about opaque fields?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opaque fields.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be valuable to a client if there were a list of explicitly opaque fields.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, all fields should be treated opaquely.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we should defer to the service proto for these considerations.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently recommended -> recommended ?

Even after API stabilization, vendoring would be preferred in Go world.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it stand for? Layout of /var/lib/containerd and /run/containerd?

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Migration is done automatically for upgrade from single previous minor release, right?

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this section is mainly about the client library.
Does it apply for plugins as well?

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Binary compatibility of plugin DLLs?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not exist at the moment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.
So, I meant it would be good to add plugin ABI to this "Not Covered" list.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AkihiroSuda The plugin ABI is not part of the project, since we are supporting them for now.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, we don't really want to make a single signing key. I'll use https://keybase.io/stevvooe.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"within" is one word in this context I think,

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Contributor

@ijc ijc Aug 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By my reading of the preceding paragraphs EOL for 1.0 is actually max(TBD+1 year, release of 1.1.0)?

@stevvooe stevvooe force-pushed the releases branch 4 times, most recently from 1f76331 to 92eb624 Compare August 9, 2017 21:15
Comment thread RELEASES.md Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about metrics?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Random-Liu
Copy link
Copy Markdown
Member

This is Cool! LGTM overall.

@crosbymichael
Copy link
Copy Markdown
Member

LGTM

@mlaventure
Copy link
Copy Markdown
Contributor

Can we have a section listing the state of "stableness" for the plugins? For instance, if we were to release today, the linux plugin could be considered stable in behavior, not so for windows. This would allow us to also include "experimental" plugins for testing

@stevvooe
Copy link
Copy Markdown
Member Author

@mlaventure Do you mind if we do this in a follow up?

@mlaventure
Copy link
Copy Markdown
Contributor

Follow SGTM.

LGTM

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: I think you're missing a word between "a" and "minor"

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be fine if we made this table the source of truth, over the policy?

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread RELEASES.md Outdated
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: another missing word, between "overview" and "the".

@stevvooe
Copy link
Copy Markdown
Member Author

@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]>
@crosbymichael
Copy link
Copy Markdown
Member

LGTM

@crosbymichael crosbymichael merged commit c7f04ce into containerd:master Aug 11, 2017
@stevvooe stevvooe deleted the releases branch August 11, 2017 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants