Cobra User Contract #1292
Cobra User Contract #1292
Conversation
Establish an understanding between user and maintainer. Set a goal for releases, security fixes and bug patches.
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. |
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😁
Establish an understanding between user and maintainer.
Set a goal for releases, security fixes and bug patches.
Closes #1232