As of Forgejo 8.0.1 the release notes were only available in the
description of the corresponding milestone which is problematic for:
- searching
- safekeeping
The release-notes-published directory is created to remedy those problems:
- a copy of all those release notes from the milestones descriptions
is added.
- a reference is added to the RELEASE-NOTES.md file which will no
longer be used.
- a symbolic link to the RELEASE-NOTES.md is added for completeness.
- the release process will be updated to populate release-notes-published.
The RELEASE-NOTES.md file is kept where it is because it is referenced
by a number of URLs.
The release-notes directory would have been a better name but it is
already used for in flight release notes waiting for the next
release. Renaming this directory or changing it is rather involved.
They are now published in the milestone in part manually edited and in
part generated by the release notes assistant. Maintaining a single
file with all the release notes is prone to conflicts and requires
manual copy/pasting that is of little value.
It may make sense to transition to a release notes directory in which
the release notes assistant could create one file per release, with a
copy of the release notes edited in the milestone. This could be more
conveniently backported and would not require human intervention.
Now that my colleague just posted a wonderful blog post https://blog.datalad.org/posts/forgejo-runner-podman-deployment/ on forgejo runner, some time I will try to add that damn codespell action to work on CI here ;) meanwhile some typos managed to sneak in and this PR should address them (one change might be functional in a test -- not sure if would cause a fail or not)
### Release notes
- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4857
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
More about codespell: https://github.com/codespell-project/codespell .
I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback.
```
❯ grep lint-spell Makefile
@echo " - lint-spell lint spelling"
@echo " - lint-spell-fix lint spelling and fix issues"
lint: lint-frontend lint-backend lint-spell
lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix
.PHONY: lint-spell
lint-spell: lint-codespell
.PHONY: lint-spell-fix
lint-spell-fix: lint-codespell-fix
❯ git grep lint- -- .forgejo/
.forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs
.forgejo/workflows/testing.yml: - run: make lint-frontend
```
so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>
I thought there would be conflicts but that they would not be so difficult to manage. Worst idea I had this week. Change to @oliverpool idea instead.
> Instead of documenting the release notes in the issue, why not in the codebase?
>
> For instance in [go](https://cs.opensource.google/go/go/+/master:doc/README.md) there is a `doc/next` folder where you add `<pr-number>.md` files which document each pr.
>
> Before the release, a script takes all those files to generate the changelog.
>
> Having them as a file tracked by git, makes them easy to review and to programmatically handle.
Refs: https://codeberg.org/forgejo/discussions/issues/155#issuecomment-1787013
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3452
Reviewed-by: Gergely Nagy <algernon@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
When in the repository settings, visiting
- `LFS` to `/{owner}/{repo}/settings/lfs`
- `Find pointer files` to `/{owner}/{repo}/settings/lfs/pointers`
- `Find commits` to `/{owner}/{repo}/settings/lfs/find?oid=...`
failed with an error 500 because of an incorrect evaluation of the
template.
Regression introduced by
cbf923e87b
A test is added to visit the page and guard against future
regressions.
Refs: https://codeberg.org/forgejo/forgejo/issues/3438
The tests in Forgejo extensively rely on admin user create to create
the first admin user. This regression was not noticed because it
is an exception and a password change will not be required.
Refs: https://codeberg.org/forgejo/forgejo/issues/3399
These release notes need a lot of attention to be good. But they are passable and ready for review.
Multiple factors made them challenging to collect:
- lack of organization Forgejo side which is going to be better for the next version
- complete reorganization of the development workflows which made it challenging to sort out what is in the release or not
- unification of the branches into a single one after the hard fork decision
Refs: https://codeberg.org/forgejo/forgejo/issues/2425
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3203
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
