Forgejo: Update to v16.0.0

[nhymxu]

Description

• Forgejo update to v16.0.0

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Package update

[hgy59]

I propose to stay on the LTS line and update to 15.0.5 instead.

[nhymxu]

@hgy59 or should I break to another package?
Like

• forgejo: for mainstream
• forgejo-lts: for LTS version

[hgy59]

@mreid-tt @th0ma7 I need your advice.
forgejo has LTS releases (v11, v15, v19) that are maintained for more than one year.
regular releases are EOL after 3 months (see https://forgejo.org/docs/v15.0/admin/release-schedule/)
That is why I proposed to create packages only for LTS releases (IMO we should handle non LTS releases like beta versions and keep the number of updates as small as possible).

[th0ma7]

Agreed, and maybe the package ahould be renamed as forgejo-lts to make things explicit. There could be an "active" pr continuously updated for testing purposes so people could download and install non lts releases.

[mreid-tt]

From my perspective, LTS releases would be the preferred approach. The main consideration is the maintenance overhead on our side.

For each upstream release, we need to review the changes, approve the package update, publish the build, and activate it in the backend. For LTS releases, where the support window is longer, that effort is easier to justify. However, if the non-LTS releases have a short support lifecycle as @hgy59 suggests, we could end up repeatedly reviewing and publishing versions that quickly become obsolete.

I'm also not convinced that having separate packages such as forgejo and forgejo-lts is the best approach. I think a model similar to .NET would be cleaner, where the package name includes the major version (for example, forgejo-16) and each major version is treated as its own package. That said, either approach introduces upgrade considerations. If users move between separately named packages, we need to consider data migration, file ownership, and permissions between installations.

Alternatively, if we want to move toward full delegation of package ownership, we could allow the package maintainer to manage the full lifecycle. The maintainer would develop through normal commits and open a pull request as usual. Once they consider the work complete, they would ensure the package checklist is fully completed and mark the PR as ready for merge.

At that point, a GitHub Action could provide the necessary guardrails by verifying that:

• the PR author matches the approved maintainer account;
• the required package checklist has been completed;
• the changes include the required package paths (cross/forgejo/ and spk/forgejo/); and
• no files outside the permitted package paths have been modified.

If those checks pass, the workflow could automatically squash and merge the pull request.

The maintainer could then also be granted a developer account in the spkrepo admin backend, allowing them to upload builds and activate releases themselves. The existing spkrepo functionality already supports this part of the workflow.

This would reduce the administrative overhead while still maintaining appropriate controls around package ownership, scope of changes, and repository integrity.

[nhymxu]

agree with prefer LTS over mainline version. It's community direction, I just upgrade because I'm using it on my device.

One concern about put major version to package name: it's make user hard to upgrade to next LTS version.

EG: user using forgejo-15 LTS, and someday, we have forgejo-17 LTS

User should uninstall old version, keep data, install new one. Very complicated.

[hgy59]

I'm also not convinced that having separate packages such as forgejo and forgejo-lts is the best approach. I think a model similar to .NET would be cleaner, where the package name includes the major version (for example, forgejo-16) and each major version is treated as its own package. That said, either approach introduces upgrade considerations. If users move between separately named packages, we need to consider data migration, file ownership, and permissions between installations.

I like the proposal of @th0ma7 to rename the package to forgejo-lts (and not create an additional package forgejo).
The idea of active PR for mainstream versions sounds interesting (github builds of mainstream versions for interested users), but since there will be updates on the LTS version in parallel, mergeconflicts will occur.

As every main version may come with data migration, my preference is still to limit to LTS releases.

[hgy59]

I like the proposal of @th0ma7 to rename the package to forgejo-lts

I must admit that renaming an existing package does not work as expected.
We must keep the current package name.

[th0ma7]

You're suggesting to change the display name, would that suffice?

[hgy59]

You're suggesting to change the display name, would that suffice?

IMO yes, it is only to document that only LTS versions will be supported.