Release process #33

jromero · 2019-12-06T17:49:53Z

readable

zmackie

Left some general clarifying questions and comments.

text/0000-release-process.md

jromero · 2019-12-10T17:14:29Z

Additional feedback:

code freeze has a negative connotation - as to sound as if the developers are no longer doing anything. Really should rename to code complete.
propose staggering pack/lifecycle releases as it would have additional positive properties.

Signed-off-by: Javier Romero <jromero@pivotal.io>

jkutner · 2019-12-12T20:05:30Z

I think an Unresolved Question is "who's on the CCB?"

Are there any drawbacks to this proposal?

zmackie · 2020-01-22T20:11:52Z

Moving to final comment period

zmackie · 2020-01-22T20:12:28Z

Disussion in WG about how to handle out of band release:

Maybe announce on slack

zmackie · 2020-01-22T20:14:24Z

This to be moved into entry in https://github.com/buildpacks/community when ratified

zmackie · 2020-01-22T20:16:30Z

text/0000-release-process.md

+    - **Release Notes**
+    - **Migration Guide**, when appropriate.
+- The release branch will be tagged as `v<version>`.
+- The release branch will be merged into `master`.


An aspect of this should also be, "on thursday, a standing item will be discussing the upcoming releases".

What this disucssion entails, I'm not certan.

Depending on the lifecycle of the release I can imagine the following:

At the start of a new release, rundown/celebration of previous release and discussion for the proposed features being worked on in the new one.

During development, quick status check/any open questions on features

Week before feature complete, a warning that it closes next Tues.

I think we should also add comms here (email, twitter, slack #announcements, etc)

@zmackie / @hone

After @zmackie and I tried to hash this out we incorporated the role of a release manager. (refer to updated doc for details). It does include the idea of relaying status during working group meetings but given the role is short lived (within feature complete) I do think the listed items lend themselves more to the PM role. Thoughts?

@jkutner added!

What is the distinction in your head of PM/Release Manager?

zmackie · 2020-01-24T18:57:12Z

Disussion in WG about how to handle out of band release:

Maybe announce on slack

We've created a #release-planning channel in slack for these discussion

Signed-off-by: Javier Romero <jromero@pivotal.io>

hone · 2020-01-24T20:01:37Z

text/0000-release-process.md

+
+_The following schedules are suggestive and subject to change based on practicality._
+
+* Release Cadence: **Monthly** on the **1st Tuesday** of the month 


Are all releases happening on the 1st Tues? Does this only apply to pack, to lifecycle? Do other pieces of software like libbuildpack or the Teknton template follow this? What about if we want to release one of them earlier b/c of a breaking change, do we need to wait a month then?

Updated the summary to present this as a template that only pack and lifecycle would use initially. The specifics on dates are agreed upon outside this document.

text/0000-release-process.md

hone · 2020-01-24T20:30:16Z

Just because this RFC hasn't been accepted, I think we can trial this whole process. Overall, I like a lot of this RFC. That being said, there are a still some outstanding questions that I think that need to be answered before this moves forward.

hone · 2020-01-24T21:38:07Z

text/0000-release-process.md

+
+A migration guide is a document which details breaking changes for migrating from prior versions.
+
+### Release Execution


Announcements via e-mail, slack, social media(?) should be included as part of the release plan so we don't forget.

jkutner · 2020-01-24T21:44:05Z

I like @hone's suggestion to trial the process. But I think there are too many open questions to finalize as is. In particular I'd like to see more clarity on:

The CCB (who's on it, how you get on it)
If this policy applies to all repos (even imgutil, and libbuildpack?)
How are security releases are handled (if we need to bypass the regular cadence)?
How lifecycle and pack interplay (do we stagger their release cycles to help w/ breaking changes?)

I think those points are captured well in the inline comments by others, but I wanted to reiterate.

nebhale · 2020-01-29T20:54:17Z

Moving back out of FCP because we were a little over-eager.

- Make it clear this is a template being applied to pack and lifecycle - Denote it excludes patches and out-of-band releases - Rename release execution to release finalization - Clarify CCB members - Add mention of tagging and release branch merging to master - Release manager role - Additional comms to release finalization Signed-off-by: Javier Romero <jromero@pivotal.io>

jromero · 2020-02-03T21:55:02Z

@jkutner we've made some changes that should shine light on some of the questions you've gathered:

The CCB (who's on it, how you get on it)

This is now answered. TL;DR; maintainers of component

If this policy applies to all repos (even imgutil, and libbuildpack?)

Summary updated. This process is intended to be a "template" that will be applied to pack and lifecycle. Other components can choose to follow it.

How are security releases are handled (if we need to bypass the regular cadence)?

Summary update. This RFC intentionally leaves out out-of-band releases to be hashed out later as they provide their own set of challenges.

How lifecycle and pack interplay (do we stagger their release cycles to help w/ breaking changes?)

Summary update. As a template, the scheduling of interoperable components is left up to a higher order as well as future definitions in an "out-of-band" release process.

ekcasey

The biggest outstanding question here for me is: what about docs? This RFC says that the maintainers of a subteam comprise the CCB. However, the docs are owned by the learning team. How will docs updates and releases be coordinated?

text/0000-release-process.md

hone · 2020-02-06T19:03:28Z

text/0000-release-process.md

+
+### Release Manager
+
+A release manager is a role assigned to an individual selected to own the release process. A release manager should be


Is the release manager assigned per release or is this a more long standing role?

hone · 2020-02-06T19:20:17Z

text/0000-release-process.md

+
+The responsibilities of the release manager include, but are not limited to:
+
+- Communicating status during working group meetings.


Should we elaborate things covered in these meetings?

zmackie · 2020-02-06T19:21:42Z

Outstanding Q: does this apply to lifecycle?

sclevine · 2020-04-15T19:25:18Z

From WG 4/15: @jromero will update to reflect that just pack is affected for now

Signed-off-by: Javier Romero <rjavier@vmware.com>

jromero · 2020-04-22T15:23:03Z

From WG 4/15: @jromero will update to reflect that just pack is affected for now

Updated

jromero · 2020-04-28T13:08:56Z

@joe / @hone any additional clarifications necessary or concerns?

hone · 2020-04-29T18:23:14Z

@jromero nope, just nitpick formality, that we should make sure to make it clear when unresolved questions are resolved/out of scope for future readings.

sclevine · 2020-05-06T19:28:19Z

Moving to FCP as of 2020-05-06, will be merged 2020-05-13 assuming no other feedback is presented.

[#33] Signed-off-by: Ben Hale <bhale@vmware.com>

jromero changed the title ~~RFC: Release process~~ Release process Dec 6, 2019

zmackie reviewed Dec 9, 2019

View reviewed changes

text/0000-release-process.md Outdated Show resolved Hide resolved

text/0000-release-process.md Show resolved Hide resolved

text/0000-release-process.md Outdated Show resolved Hide resolved

Release process

6b59e91

Signed-off-by: Javier Romero <jromero@pivotal.io>

jromero force-pushed the release-process branch from 2353369 to 6b59e91 Compare December 12, 2019 18:59

sclevine requested review from sclevine, hone, jkutner and nebhale December 12, 2019 19:50

nebhale approved these changes Jan 8, 2020

View reviewed changes

nebhale added the Project label Jan 9, 2020

zmackie added the roadmap/release-process label Jan 15, 2020

sclevine approved these changes Jan 22, 2020

View reviewed changes

zmackie added the Final Comment Period label Jan 22, 2020

zmackie reviewed Jan 22, 2020

View reviewed changes

simonjjones added 2 commits January 24, 2020 13:47

(WIP) Alternatives, prior art and questions for release process

2c3753e

Signed-off-by: Javier Romero <jromero@pivotal.io>

Additional alternate proposals for release approval and notes

d304030

Signed-off-by: Javier Romero <jromero@pivotal.io>

jromero force-pushed the release-process branch from 206c394 to d304030 Compare January 24, 2020 19:47

hone reviewed Jan 24, 2020

View reviewed changes

text/0000-release-process.md Outdated Show resolved Hide resolved

hone reviewed Jan 24, 2020

View reviewed changes

text/0000-release-process.md Outdated Show resolved Hide resolved

hone reviewed Jan 24, 2020

View reviewed changes

text/0000-release-process.md Outdated Show resolved Hide resolved

hone reviewed Jan 24, 2020

View reviewed changes

zmackie removed the Final Comment Period label Jan 29, 2020

hone mentioned this pull request Jan 30, 2020

RFC: spec API releases #49

Merged

ekcasey reviewed Feb 5, 2020

View reviewed changes

text/0000-release-process.md Show resolved Hide resolved

hone reviewed Feb 6, 2020

View reviewed changes

zmackie added the status/hold label Feb 6, 2020

sclevine removed the status/hold label Apr 15, 2020

Process will not initially apply to lifecycle

cd029d9

Signed-off-by: Javier Romero <rjavier@vmware.com>

jromero requested a review from a team as a code owner April 22, 2020 15:22

jromero requested review from ekcasey and hone April 22, 2020 15:22

ekcasey approved these changes Apr 22, 2020

View reviewed changes

hone approved these changes Apr 29, 2020

View reviewed changes

jkutner approved these changes Apr 30, 2020

View reviewed changes

nebhale added the Final Comment Period label May 13, 2020

nebhale added a commit that referenced this pull request May 15, 2020

RFC #39

4172177

[#33] Signed-off-by: Ben Hale <bhale@vmware.com>

nebhale merged commit 243ec7a into buildpacks:master May 15, 2020

ekcasey removed the Final Comment Period label Oct 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release process #33

Release process #33

jromero commented Dec 6, 2019

zmackie left a comment

jromero commented Dec 10, 2019

jkutner commented Dec 12, 2019

zmackie commented Jan 22, 2020

zmackie commented Jan 22, 2020

zmackie commented Jan 22, 2020 •

edited

Loading

zmackie Jan 22, 2020

hone Jan 24, 2020

jkutner Jan 24, 2020

jromero Jan 31, 2020

jromero Jan 31, 2020

hone Feb 6, 2020

zmackie commented Jan 24, 2020

hone Jan 24, 2020 •

edited

Loading

jromero Jan 31, 2020

hone commented Jan 24, 2020 •

edited

Loading

hone Jan 24, 2020

jromero Jan 31, 2020

jkutner commented Jan 24, 2020

nebhale commented Jan 29, 2020

jromero commented Feb 3, 2020

ekcasey left a comment

hone Feb 6, 2020

hone Feb 6, 2020

zmackie commented Feb 6, 2020

sclevine commented Apr 15, 2020

jromero commented Apr 22, 2020

jromero commented Apr 28, 2020

hone commented Apr 29, 2020

sclevine commented May 6, 2020


		_The following schedules are suggestive and subject to change based on practicality._

		* Release Cadence: Monthly on the 1st Tuesday of the month


		A migration guide is a document which details breaking changes for migrating from prior versions.

		### Release Execution


		### Release Manager

		A release manager is a role assigned to an individual selected to own the release process. A release manager should be


		The responsibilities of the release manager include, but are not limited to:

		- Communicating status during working group meetings.

Release process #33

Release process #33

Conversation

jromero commented Dec 6, 2019

zmackie left a comment

Choose a reason for hiding this comment

jromero commented Dec 10, 2019

jkutner commented Dec 12, 2019

zmackie commented Jan 22, 2020

zmackie commented Jan 22, 2020

zmackie commented Jan 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zmackie commented Jan 24, 2020

hone Jan 24, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hone commented Jan 24, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkutner commented Jan 24, 2020

nebhale commented Jan 29, 2020

jromero commented Feb 3, 2020

ekcasey left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zmackie commented Feb 6, 2020

sclevine commented Apr 15, 2020

jromero commented Apr 22, 2020

jromero commented Apr 28, 2020

hone commented Apr 29, 2020

sclevine commented May 6, 2020

zmackie commented Jan 22, 2020 •

edited

Loading

hone Jan 24, 2020 •

edited

Loading

hone commented Jan 24, 2020 •

edited

Loading