Document release process for editions #325
Conversation
There was a problem hiding this comment.
Provided a different suggestion on one of the headings.
Also waiting for the "other findings" to be documented as issues before closing #279
| 1. Change all "No edition set" entries in the release tables of the latest YAML file for each event type to a link to the not yet existing edition tag. | ||
| 1. Claim the edition in [versioning.md](../eiffel-syntax-and-usage/versioning.md), including a short summary of the changes in the edition. | ||
| 1. When the pull request has been merged, create and push an "edition-\<name>" annotated tag (use `git tag -a`). The tag comment could include a short version of the included changes to the protocol. Any new major versions of event types should be called out. | ||
| 1. Create a GitHub release based on the newly pushed tag. The tag comment can probably be reused as the release description. |
There was a problem hiding this comment.
Are there any settings when creating the release e.g. https://github.com/eiffel-community/eiffel-remrem-publish/releases has different layout of the release. Any tick boxes you need to mark?
There was a problem hiding this comment.
They are very similar to me: https://github.com/eiffel-community/eiffel/releases vs https://github.com/eiffel-community/eiffel-remrem-publish/releases. What are the differences you refer to, @m-linner-ericsson ?
There was a problem hiding this comment.
The red circled parts are missing in 2.0.26
There was a problem hiding this comment.
It seems that it is possible to generate a nice looking release note once a tag is selected, and that release note will include the Contributors and maybe more interesting stuff.
I propose that we approve the current instruction as-is, and then once we have tested this feature along with the upcoming release we could possibly update the instruction to recommend/require that the release notes are generated using that button.
There was a problem hiding this comment.
Interesting, I hadn't seen that feature. Let's try it out for Arica. There are ways of configuring what PRs to include and that's something we could use to only include PRs affecting the protocol (if we start labeling issues and PRs with e.g. a "protocol" label, but I think we should do that anyway).
|
I'm ok with your latest changes @magnusbaeck . |
Applicable Issues
Fixes #279
Description of the Change
Adds documentation on the use of milestones and an edition release checklist.
Alternate Designs
None.
Benefits
Less mental burden when releasing an edition and decreased risk of forgetting anythign.
Possible Drawbacks
None.
Sign-off
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
Signed-off-by: Magnus Bäck <magnus.back@axis.com>