Skip to content
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

Cobra User Contract #1292

Merged
merged 2 commits into from Jan 26, 2021
Merged

Cobra User Contract #1292

merged 2 commits into from Jan 26, 2021

Conversation

@jharshman
Copy link
Collaborator

@jharshman jharshman commented Dec 4, 2020

Establish an understanding between user and maintainer.
Set a goal for releases, security fixes and bug patches.

Closes #1232

Establish an understanding between user and maintainer.
Set a goal for releases, security fixes and bug patches.
@jharshman jharshman self-assigned this Dec 4, 2020
@jharshman jharshman requested review from jpmcb and wfernandes Dec 4, 2020
Copy link
Contributor

@marckhouzam marckhouzam left a comment

I love the predictability proposed here. As a user and contributor, it is really appreciated.

CONDUCT.md Outdated
There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging.

### CI Testing
Maintainers will ensure the the Cobra test suite utilizes the current supported versions of Golang.

This comment has been minimized.

@marckhouzam

marckhouzam Dec 4, 2020
Contributor

double "the"

CONDUCT.md Outdated
Maintainers will ensure the the Cobra test suite utilizes the current supported versions of Golang.

### Disclaimer
Changes to this document and the contents therin are at the discretion of the maintainers.

This comment has been minimized.

@marckhouzam

marckhouzam Dec 4, 2020
Contributor

I think it's "therein" unless you are Polish, according to google anyway 😁

Cobra maintainers will use GitHub issues and the [#cobra slack channel](https://gophers.slack.com/archives/CD3LP1199) as the primary means of communication with the community. This is to foster open communication with all users and contributors.

### Breaking Changes
Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra.

This comment has been minimized.

@marckhouzam

marckhouzam Dec 4, 2020
Contributor

I'm curious about this. It seems to indicate that once a release is out, the master branch can accept breaking changes such as removing functions.

But such changes will break clients at the next release, so I wonder if that is really what the sentence aims to convey?

This comment has been minimized.

@jharshman

jharshman Dec 4, 2020
Author Collaborator

@marckhouzam, this sentence does feel a bit off. The point we are trying to convey here is that breaking changes should only show up in major releases. Where we keep those breaking changes til then is a matter of discussion.

This comment has been minimized.

@jharshman

jharshman Dec 4, 2020
Author Collaborator

although... this might be fine if we consider that we might create release branches that are maintained through their lifecycle.
In that case all changes hit master and are then merged into the currently maintained release branch and published as minor releases until the next major release.

This comment has been minimized.

@marckhouzam

marckhouzam Dec 5, 2020
Contributor

That would work. But as you point out every PR would need to come in for the release branch and the master branch (except breaking PRs, but those are rare anyway).

Also, it makes me wonder about patch releases. Would there be any? If so, from what branch would they be built?

If you're interested, here's the way helm does its release strategy.

  • a minor release triggers a new release branch. After the release only bug fixes go in that release branch for future patch releases
  • the master branch is then used for the next minor release, so PRs target the master branch (which is simple for new contributors) and only bug fixes need to be cherry-picked into the release branch (this is relatively simple and is done by the maintainer on the patch release day, based on a PR tag)
  • breaking changes are not committed anywhere but instead the PR is scheduled for the next major milestone; this works well because breaking changes are rare

I feel this is a pretty simple process but it could be that I'm used to it 😁

@jpmcb
jpmcb approved these changes Jan 22, 2021
Copy link
Collaborator

@jpmcb jpmcb left a comment

This looks ready to go to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

3 participants