Skip to content

Commit

Permalink
Update to 5 in STEP and README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
github-actions committed Jun 1, 2023
1 parent 2826428 commit 517c54a
Show file tree
Hide file tree
Showing 2 changed files with 29 additions and 23 deletions.
2 changes: 1 addition & 1 deletion .github/steps/-step.txt
Original file line number Diff line number Diff line change
@@ -1 +1 @@
4
5
50 changes: 28 additions & 22 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,39 +16,45 @@ _Create a release based workflow that is built on the foundations of the GitHub
</header>

<!--
<<< Author notes: Step 4 >>>
<<< Author notes: Step 5 >>>
Start this step by acknowledging the previous step.
Define terms and link to docs.github.com.
-->

## Step 4: Generate release notes and merge
## Step 5: Finalize the release

_Thanks for opening that pull request :dancer:_
_Awesome work on the release notes :+1:_

### Automatically generated release notes
### Finalizing releases

[Automatically generated release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) provide an automated alternative to manually writing release notes for your GitHub releases. With automatically generated release notes, you can quickly generate an overview of the contents of a release. Automatically generated release notes include a list of merged pull requests, a list of contributors to the release, and a link to a full changelog. You can also customize your release notes once they are generated.
It's important to be aware of the information what will be visible in that release. In the pre-release, the version and commit messages are visible.

### :keyboard: Activity: Generate release notes
![image](https://user-images.githubusercontent.com/13326548/47883578-bdba7780-ddea-11e8-84b8-563e12f02ca6.png)

### Semantic versioning

Semantic versioning is a formal convention for specifying compatibility. It uses a three-part version number: **major version**; **minor version**; and **patch**. Version numbers convey meaning about the underlying code and what has been modified. For example, versioning could be handled as follows:

| Code status | Stage | Rule | Example version |
| ------------------------------- | ------------- | ---------------------------------------------------------------------- | --------------- |
| First release | New product | Start with 1.0.0 | 1.0.0 |
| Backward compatible fix | Patch release | Increment the third digit | 1.0.1 |
| Backward compatible new feature | Minor release | Increment the middle digit and reset the last digit to zero | 1.1.0 |
| Breaking updates | Major release | Increment the first digit and reset the middle and last digits to zero | 2.0.0 |

Check out this article on [Semantic versioning](https://semver.org/) to learn more.

### Finalize the release

Now let's change our recently automated release from _draft_ to _latest release_.

### :keyboard: Activity: Finalize release

1. In a separate tab, go to the **Releases** page for this repository.
- _Tip: To reach this page, click the **Code** tab at the top of your repository. Then, find the navigation bar below the repository description, and click the **Releases** heading link._
1. Click the **Draft a new release** button.
1. In the field for _Tag version_, specify `v1.0.0`.
1. To the right of the tag dropdown, click the _Target_ dropddown and select the `release-v1.0` branch.
- _Tip: This is temporary in order to generate release notes based on the changes in this branch._
1. To the top right of the description text box, click **Generate release notes**.
1. Review the release notes in the text box and customize the content if desired.
1. Set the _Target_ branch back to the `main`, as this is the branch you want to create your tag on once the release branch is merged.
1. Click **Save draft**, as you will publish this release in the next step.

You can now [merge](https://docs.github.com/en/get-started/quickstart/github-glossary#merge) your pull request!

### :keyboard: Activity: Merge into main

1. In a separate tab, go to the **Pull requests** page for this repository.
1. Open your **Release v1.0** pull request.
1. Click **Merge pull request**.
1. Click the **Edit** button next to your draft release.
1. Ensure the _Target_ branch is set to `main`.
1. Click **Publish release**.
1. Wait about 20 seconds then refresh this page (the one you're following instructions from). [GitHub Actions](https://docs.github.com/en/actions) will automatically update to the next step.

<footer>
Expand Down

0 comments on commit 517c54a

Please sign in to comment.