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

new package: Update example to subject: verb version #496

Merged
merged 5 commits into from
Mar 1, 2024
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.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/packaging/creating-a-new-package.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,7 @@ There should be a summary line (with the package name), a blank line, and then t
Here is an example in our standard format (make sure to check the box in the checklist):

```
tree: initial inclusion in the repository
tree: Add at v2.1.1

**Summary**

Expand Down
25 changes: 23 additions & 2 deletions docs/packaging/updating-an-existing-package.md
Original file line number Diff line number Diff line change
Expand Up @@ -112,9 +112,17 @@
git commit
```

### Commit message format for updated / bumped packages
## Commit message format

There should be a meaningful summary line (which starts with the package name), a blank line, and then the rest of the commit message.
With the switch to a single large package git repository, having a regular, easy-to-read, and standardized commit message format helps enable quick and efficient "at-a-glance" reading of git commit messages for packagers and Staff alike.

Each commit message should consist of a meaningful summary line (which starts with the package name), a blank line, and then the rest of the commit message body.

Note that `[NFC]` (listed in an example below) is an abbreviation for "No Functional Change".

### Package update

The following guidelines apply to the commit message body:

- Bullet point lists should start with a dash.
- Include a changelog with a brief list of updates from the upstream release notes, with no links or issue numbers.
Expand All @@ -131,7 +139,7 @@
- #123 fixed a thing
```

If you want to intentionally link to another issue in this repository, the right way is to use our repo name. Ex:

Check warning on line 142 in docs/packaging/updating-an-existing-package.md

View workflow job for this annotation

GitHub Actions / spellcheck

Unknown word (repo)

```
Fixes getsolus/packages#issuenumber
Expand Down Expand Up @@ -167,6 +175,19 @@
- [ ] Package was built and tested against unstable
```

### Other commit message format examples
EbonJaeger marked this conversation as resolved.
Show resolved Hide resolved

In the cases where you are not updating a package to a new version, but simply applying a patch or fixing an existing version, the following commit messages are considered suitable:

- Add the `homepage` metadata key:
- `package: Add homepage`
- Fix a packaging issue (including adding a patch to fix the package)
- `package: Fix (...)`
- Updating a README, [monitoring.yml file](monitoring.yml.md) or other stuff that does not directly _change_ the package, meaning the package release number didn't need a bump:
- `package: [NFC] Add README.md and monitoring.yml`
EbonJaeger marked this conversation as resolved.
Show resolved Hide resolved

As stated previously, `[NFC]` is an abbreviation of "No Functional Change".

For more information on suitable commit messages, please check the [tooling central documentation](https://github.com/solus-project/tooling-central/blob/master/README.rst#using-git).

Next, you'll [submit a pull request for review](submitting-a-pull-request.md).