Skip to content

Commit 59b1c77

Browse files
Update to 5 in STEP and README.md
1 parent 61d5e1f commit 59b1c77

File tree

2 files changed

+29
-23
lines changed

2 files changed

+29
-23
lines changed

.github/steps/-step.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
4
1+
5

README.md

Lines changed: 28 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -16,39 +16,45 @@ _Create a release based workflow that is built on the foundations of the GitHub
1616
</header>
1717

1818
<!--
19-
<<< Author notes: Step 4 >>>
19+
<<< Author notes: Step 5 >>>
2020
Start this step by acknowledging the previous step.
2121
Define terms and link to docs.github.com.
2222
-->
2323

24-
## Step 4: Generate release notes and merge
24+
## Step 5: Finalize the release
2525

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

28-
### Automatically generated release notes
28+
### Finalizing releases
2929

30-
[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.
30+
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.
3131

32-
### :keyboard: Activity: Generate release notes
32+
![image](https://user-images.githubusercontent.com/13326548/47883578-bdba7780-ddea-11e8-84b8-563e12f02ca6.png)
33+
34+
### Semantic versioning
35+
36+
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:
37+
38+
| Code status | Stage | Rule | Example version |
39+
| ------------------------------- | ------------- | ---------------------------------------------------------------------- | --------------- |
40+
| First release | New product | Start with 1.0.0 | 1.0.0 |
41+
| Backward compatible fix | Patch release | Increment the third digit | 1.0.1 |
42+
| Backward compatible new feature | Minor release | Increment the middle digit and reset the last digit to zero | 1.1.0 |
43+
| Breaking updates | Major release | Increment the first digit and reset the middle and last digits to zero | 2.0.0 |
44+
45+
Check out this article on [Semantic versioning](https://semver.org/) to learn more.
46+
47+
### Finalize the release
48+
49+
Now let's change our recently automated release from _draft_ to _latest release_.
50+
51+
### :keyboard: Activity: Finalize release
3352

3453
1. In a separate tab, go to the **Releases** page for this repository.
3554
- _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._
36-
1. Click the **Draft a new release** button.
37-
1. In the field for _Tag version_, specify `v1.0.0`.
38-
1. To the right of the tag dropdown, click the _Target_ dropddown and select the `release-v1.0` branch.
39-
- _Tip: This is temporary in order to generate release notes based on the changes in this branch._
40-
1. To the top right of the description text box, click **Generate release notes**.
41-
1. Review the release notes in the text box and customize the content if desired.
42-
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.
43-
1. Click **Save draft**, as you will publish this release in the next step.
44-
45-
You can now [merge](https://docs.github.com/en/get-started/quickstart/github-glossary#merge) your pull request!
46-
47-
### :keyboard: Activity: Merge into main
48-
49-
1. In a separate tab, go to the **Pull requests** page for this repository.
50-
1. Open your **Release v1.0** pull request.
51-
1. Click **Merge pull request**.
55+
1. Click the **Edit** button next to your draft release.
56+
1. Ensure the _Target_ branch is set to `main`.
57+
1. Click **Publish release**.
5258
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.
5359

5460
<footer>

0 commit comments

Comments
 (0)