Bonjour,
The Forgejo v1.20 release will come with three kind of significant changes:
- UI
- Actions
- New queue subsystem
Actions won't be production ready and still marked as experimental. The UI changes and the new subsystem have very low test coverage. If there are unexpected breakage in Actions, that's not disruptive because that's what experimental is about. Regressions introduced because of the UI and the new queue systems are more concerning.
To manage this risk I propose to:
- Switch to semantic versioning and release Forgejo v5.0.0+0-gitea-1.20.0-rc0 upon the first Gitea v1.20 release candidate
- Publish one (or more) release candidates when Gitea v1.20.0 is released: Forgejo v5.0.5+0-gitea-1.20.0, Forgejo v5.0.6+0-gitea-1.20.1, etc.
This can be explained roughly as follows:
- Forgejo switches to semantic versioning with a suffix including the matching Gitea version number for clarity
- Forgejo now has its own release cycle that is not necessarily exactly the same as Gitea
- Forgejo v5.0.0 will have an extended release candidate period because the Gitea version it includes will need a few point releases to be robust enough for production
The people who are eager to get the latest features and who are not concerned with potential regressions can install the release candidates and decide for themselves it is stable enough. Those who prefer to be on solid ground can just wait for the Forgejo release.
As of Forgejo v1.19 release candidates are published in the https://codeberg.org/forgejo-experimental/ organization so any kind of script that automatically takes whatever is published on https://codeberg.org/forgejo/ won't accidentally install a release candidate. In addition the container images do not have a latest tag which protects installations that need stability from accidentally switching to a major version.
How does that sound?
Bonjour,
The Forgejo v1.20 release will come with three kind of significant changes:
* UI
* Actions
* New queue subsystem
Actions won't be production ready and still marked as experimental. The UI changes and the new subsystem have very low test coverage. If there are unexpected breakage in Actions, that's not disruptive because that's what experimental is about. Regressions introduced because of the UI and the new queue systems are more concerning.
To manage this risk I propose to:
* Switch to semantic versioning and release Forgejo v5.0.0+0-gitea-1.20.0-rc0 upon the first Gitea v1.20 release candidate
* Publish one (or more) release candidates when Gitea v1.20.0 is released: Forgejo v5.0.5+0-gitea-1.20.0, Forgejo v5.0.6+0-gitea-1.20.1, etc.
This can be explained roughly as follows:
* Forgejo switches to semantic versioning with a suffix including the matching Gitea version number for clarity
* Forgejo now has its own release cycle that is not necessarily exactly the same as Gitea
* Forgejo v5.0.0 will have an extended release candidate period because the Gitea version it includes will need a few point releases to be robust enough for production
The people who are eager to get the latest features and who are not concerned with potential regressions can install the release candidates and decide for themselves it is stable enough. Those who prefer to be on solid ground can just wait for the Forgejo release.
As of Forgejo v1.19 release candidates are published in the https://codeberg.org/forgejo-experimental/ organization so any kind of script that automatically takes whatever is published on https://codeberg.org/forgejo/ won't accidentally install a release candidate. In addition the container images do not have a latest tag which protects installations that need stability from accidentally switching to a major version.
How does that sound?