Conversation
dhalperi
force-pushed
the
release-guide
branch
from
d348bf0 to
0254cbe
Compare
contribute/release-guide.md
Outdated
|
|
||
| Anybody can propose a release on the dev@ mailing list, giving a solid argument and nominating a committer as the Release Manager (including themselves). There’s no formal process, no vote requirements, and no timing requirements. Any objections should be resolved by consensus before starting the release. | ||
|
|
||
| In general, the community prefers to have a rotating set of 3-5 Release Managers. Keeping a small core set of managers allows enough people to build expertise in this area and improve processes over time, without Release Managers needing to re-learn the processes for each release. That said, if you are a committer interested in serving the community in this way, please reach out to us on the dev@ mailing list. |
There was a problem hiding this comment.
@dhalperi would suggest to have this: "please reach out to us on the dev@ mailing list."
To "please reach out to the community on the dev@ mailing list" unless there is a specific list for committers / PMC members
|
|
||
| ### Create a new version in JIRA | ||
|
|
||
| When contributors resolve an issue in JIRA, they are tagging it with a release that will contain their changes. With the release currently underway, new issues should be resolved against a subsequent future release. Therefore, you should create a release item for this subsequent release, as follows: |
There was a problem hiding this comment.
@dhalperi I was under the impression that committers who resolve the issues determine the suitable release for the fix. Please correct me if I am wrong. Generally seen that contributors push code to the master and then they get added to branches. If separation is need a new PR/ patch would be done specifically for that branch.
There was a problem hiding this comment.
Typically fixes will go into the development version, which is the next minor release. We additionally will cherry-pick from master into release branches, but only for hot fixes. What you are proposing is good, and a more flexible process, but we are just not there yet. For now I'll keep as-is but this is something we should consider doing in the near future.
Apparently it times out on travis even though all failing links are valid:
2 participants
R: @davorbonaci