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

Document release process for editions #325

Merged
merged 3 commits into from
Nov 3, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 2 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,3 +86,5 @@ Visit [Eiffel Community](https://eiffel-community.github.io) to get started and
1. [Custom Data](./customization/custom-data.md)
1. Extensions
1. [Eiffel Operations Extension](https://github.com/Ericsson/eiffel-operations-extension)
1. Releases and Milestones
1. [Release process](./releases-and-milestones/release-process.md)
2 changes: 1 addition & 1 deletion eiffel-syntax-and-usage/event-schemas.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Both schemas and documentation files are generated from _schema definition files
| `_links.<link type>.targets.types` | A string array of event names that the link type may point to. Must be non-empty if `any_type` is false, and must be empty if `any_type` is true. |
| `_history` | An array of objects describing the event type's version history, up to and including the current version. The items should be sorted in reverse order. |
| `_history.version` | The event version described in this item. |
| `_history.introduced_in` | A description of the edition in which this item's event version was introduced. |
| `_history.introduced_in` | The first edition in which this version was the latest for this event type. If the version hasn't been released in a protocol edition or if there are newer versions in the first edition where it was introduced, use "No edition set". |
| `_history.changes` | A short description of the changes in this item's event version. |
| `_examples` | An array of objects describing examples of this event. |
| `_examples.title` | The name of the example. |
Expand Down
2 changes: 2 additions & 0 deletions eiffel-syntax-and-usage/versioning.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,8 @@ That being said, to facilitate compatibility and consistency, the Eiffel protoco
| Toulouse | [edition-toulouse](../../../tree/edition-toulouse) | Stepped major version of TERCC. Updated FLOW_CONTEXT link type, resulting in new minor version of all event types. |
| Bordeaux | [edition-bordeaux](../../../tree/edition-bordeaux) | Initial edition. |

The [schema definition files](event-schemas.md) document the mappings between event versions and editions.

## Rules for patch, minor and major versions
In the case of a communication protocol, applying Semantic Versioning is not as straight-forward as for a regular software implementation. The ground rule is to consider backwards compatibility from the perspective of the consumer of an event. Below are rules and examples of how this applies to the Eiffel protocol.

Expand Down
41 changes: 41 additions & 0 deletions releases-and-milestones/release-process.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
<!---
Copyright 2022 Axis Communications AB.
For a full list of individual contributors, please see the commit history.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--->

# Release process

This document describes the release process for Eiffel editions.

## Pre-release activities

Look up the name of the next edition in the [Versioning](../eiffel-syntax-and-usage/versioning.md) document.

GitHub [milestones](https://github.com/eiffel-community/eiffel/milestones?state=open) are used to track the proposed contents of an upcoming edition. Milestones are named "Edition \<name>", e.g. "Edition Arica". Issues, not pull requests, are added to the milestone.

## Making a release

When all issues in the scope of the edition have been closed and it's time to make the release, follow these steps:

1. Verify that all issues in the [milestone](https://github.com/eiffel-community/eiffel/milestones?state=open) are closed.
1. Create a pull request with the following changes (see [PR 277](https://github.com/eiffel-community/eiffel/pull/277) for reference):
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

The red circled parts are missing in 2.0.26

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
image

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

1. Create issue(s) for updating other repositories to reference the new edition:
1. [eiffel-sepia](https://github.com/eiffel-community/eiffel-sepia)
1. Announce the new edition on the eiffel-community mailing list, LinkedIn, and Slack and ask maintainers of other repositories to make necessary updates.
1. Mark the edition's milestone as closed.