1
0
Fork 0
Commit graph

2 commits

Author SHA1 Message Date
Earl Warren
1171069ced
docs(release-notes): flatten release-notes files
It is not for the developer to keep them sorted in a hierarchy when
the release they belong to can be deduced from the tag of the release
into which they were merged. The release notes assistant does that
work instead.

Some files appeared in more than one directory (feat and fix for
instance) when the PR contains multiple unrelated commits which is
what happens on a regular basis with the weekly cherry-pick of
Gitea. Those files were merged into one and each line changed to start
with a conventional commit prefix (feat: fix:).

Each line in a file will be a separate line in the release notes, they
are not groupped together even when they relate to the same PR. The
determination of the category in which they should be displayed will
be based on regular expressions using either the PR title or the line
to add to the release notes itself.

Unify the content of each file to either be a bullet list of
independent pull requests or be folded into a single line if it is
multiline. Multiline content belongs to the documentation.

Refs: https://code.forgejo.org/forgejo/release-notes-assistant
Refs: https://www.conventionalcommits.org/en/v1.0.0/
2024-07-11 14:20:34 +02:00
0ko
0a026a9cd8 Reorder repo tabs (#4139)
More info in the linked PR.

---

Make positioning of the repo tabs make more sense. This is an isolated implementation for one of many changes discussed in the referenced issue, it will work good without the other changes too.

## Changes

- Actions are moved to the edge. This tab is the least relevant to both visitors and developers. The first don't really need it at all, the second only visit it when something goes unexpected (run did not happen or attached to the wrong event), or just to see the run queue to know when their actions is going to get processed. This is not a tab with always-relevant information.

- put Packages after releases. The Packages are like a download page for Releases, but for released packages instead of binaries/source code. It is relevant to Releases, so it should stay close, but it is secondary to Releases by importance. For example, because they don't actually contain release notes unlike Releases.

- the above makes Projects appear next to Issues and Pull requests which I think is nice as they're related.

## Preview

### v7
https://codeberg.org/attachments/c434e8fd-aaab-4c27-9071-2a3ba68ad4b7

### This PR
https://codeberg.org/attachments/74743c03-883e-40cf-8cb1-384d1d8cf63c

Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4139
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Beowulf <beowulf@noreply.codeberg.org>
2024-06-16 12:36:41 +00:00