v8.0 feature freeze 1 July 2024 #180

earl-warren commented 2024年06月22日 09:43:10 +02:00

If you agree to a feature freeze on 1 July 2024, 👍 this comment. If you have no opinion but saw this message, 👀. If you have concerns, please add a comment.

---

Forgejo v8.0 is scheduled to be published 17 July 2024 and the release notes have been drafted on a rolling basis. There are about 25 pull requests in flight and two release blockers in need of attention.

• v8.0 release checklist
• draft release notes
• pull requests in flight
• release blockers

My general impression is that this release is going to require a lot less work in the last days because the work was distributed and every Forgejo contributor made an extra effort, for each pull request. I also think it is less likely to contain regressions or security issues because the effort on writing tests increased and some refactors were skipped when their benefits were unclear.

That does not mean there will not be regressions: bugs happen and Forgejo v7.0 had a fair share of those. But they are less likely to originate from changes that are untested. This was the strongest incentive for the hard fork and it begins to pay off. As of this month, a strict requirement is now maintained for backporting changes to v7.0 and each of them is tested, even for oneliners. However, commits cherry-picked weekly from Gitea are still accepted even when they are entirely untested, with a few exceptions.

The feature freeze period is meant to allow for:

• one round manual testing. There are detailed instructions for ~60 pull requests that do not have automated tests (out of the ~300 that were merged). It is tedious but methodical. Before this release there were no such instructions and no way to know what to test.
• discovering bugs in the new v8.0 features before the release instead of taking the risk that a new feature merged 24h before the release introduces a bug that is discovered immediately after the release.

**If you agree to a feature freeze on 1 July 2024, 👍 this comment**. If you have no opinion but saw this message, 👀. If you have concerns, please add a comment. --- Forgejo v8.0 is scheduled to be published [17 July 2024](https://forgejo.org/docs/next/developer/release/#release-cycle) and the release notes have been [drafted on a rolling basis](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/release-notes/8.0.0). There are about [25 pull requests in flight](https://codeberg.org/forgejo/forgejo/pulls) and [two release blockers](https://codeberg.org/forgejo/forgejo/issues?labels=222746) in need of attention. * [v8.0 release checklist](https://codeberg.org/forgejo/forgejo/issues/4153) * [draft release notes](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/release-notes/8.0.0) * [pull requests in flight](https://codeberg.org/forgejo/forgejo/pulls) * [release blockers](https://codeberg.org/forgejo/forgejo/issues?labels=222746) My general impression is that this release is going to require a lot less work in the last days because the work was distributed and every Forgejo contributor made an extra effort, for each pull request. I also think it is less likely to contain regressions or security issues because the effort on writing tests increased and some refactors were skipped when their benefits were unclear. That does not mean there will not be regressions: bugs happen and Forgejo v7.0 had a fair share of those. But they are less likely to originate from changes that are untested. This was the strongest incentive for the hard fork and it begins to pay off. As of this month, a strict requirement is now maintained for backporting changes to v7.0 and each of them is tested, even for [oneliners](https://codeberg.org/forgejo/forgejo/pulls/4151/files). However, commits [cherry-picked weekly from Gitea](https://codeberg.org/forgejo/forgejo/pulls?q=week%202024) are still accepted even when they are entirely untested, with a few exceptions. The feature freeze period is meant to allow for: * **one round manual testing**. There are detailed [instructions for ~60 pull requests](https://codeberg.org/forgejo/forgejo/pulls?labels=201028&milestone=6042) that do not have automated tests (out of the ~300 that were merged). It is tedious but methodical. Before this release there were no such instructions and no way to know what to test. * **discovering bugs in the new v8.0 features** before the release instead of taking the risk that a new feature merged 24h before the release introduces a bug that is discovered immediately after the release.

fnetX commented 2024年06月22日 13:18:26 +02:00

I must admit that this is a little less time than what I hoped for to do another round of user testing with the new version. It will show valuable feedback and often result in simple fixes in the templates. But still, they are changes and even template logic can result in significant regressions.

I must admit that this is a little less time than what I hoped for to do another round of user testing with the new version. It will show valuable feedback and often result in simple fixes in the templates. But still, they are changes and even template logic can result in significant regressions.

oliverpool commented 2024年06月22日 14:13:22 +02:00

Before making another semantic release, I think it would be important to agree on what breaking changes mean: forgejo/governance#124 (all inputs have been taken into account, but not many people reacted/commented).

Before making another semantic release, I think it would be important to agree on what breaking changes mean: https://codeberg.org/forgejo/governance/issues/124 (all inputs have been taken into account, but not many people reacted/commented).

earl-warren commented 2024年06月22日 15:25:38 +02:00

@oliverpool do you mean that what constitutes a breaking change should be decided before v8.0 is published? Or before whatever version comes next is published?

@oliverpool do you mean that what constitutes a breaking change should be decided before v8.0 is published? Or before whatever version comes next is published?

earl-warren commented 2024年06月22日 15:30:23 +02:00

I must admit that this is a little less time than what I hoped for to do another round of user testing with the new version.

To be clear, by "user testing" I think you mean inviting users to try the new version on a copy of the Codeberg instance that runs the next version, with the entire database. Right? If so, it has been very valuable for v7.0, indeed.

So you would like the feature freeze happens sooner so there is more time for user testing? For instance 24 June which gives one more week?

> I must admit that this is a little less time than what I hoped for to do another round of user testing with the new version. To be clear, by "user testing" I think you mean inviting users to try the new version on a copy of the Codeberg instance that runs the next version, with the entire database. Right? If so, it has been very valuable for v7.0, indeed. So you would like the feature freeze happens sooner so there is more time for user testing? For instance 24 June which gives one more week?

earl-warren commented 2024年06月22日 15:32:43 +02:00

One idea would be to have two freeze periods:

• 24 June => no merge that require manual testing
• 1 July => no merge that introduce a new feature

What do you think?

One idea would be to have **two** freeze periods: * 24 June => no merge that require manual testing * 1 July => no merge that introduce a new feature What do you think?

fnetX commented 2024年06月25日 08:49:37 +02:00

I rather wanted to consider how to proceed with findings in User Testing: What if we notice that an upcoming feature is basically unusable in the current form or needs serious improvement. Will it allow hotfixes that require manual testing, for example, even after the deadline?

So fixes to features that address usability. Not new features, not bugfixes. Something inbetween.

I rather wanted to consider how to proceed with findings in User Testing: What if we notice that an upcoming feature is basically unusable in the current form or needs serious improvement. Will it allow hotfixes that require manual testing, for example, even after the deadline? So fixes to features that address usability. Not new features, not bugfixes. Something inbetween.

earl-warren commented 2024年06月25日 10:30:52 +02:00

What if we notice that an upcoming feature is basically unusable in the current form or needs serious improvement.

It is reverted in the v8.0 branch and pushed to the next release. Such revert could be difficult in theory. In practice I'm quite sure it will be trivial for v8.0.

Will it allow hotfixes that require manual testing, for example, even after the deadline?

In the current state of things there are bug fixes in the UI that cannot have automated testing at all because the infrastructure is just not there. Everything that involves JS & CSS is pretty much in this state and require manual testing. Automated testing in all other areas, including templates changes, can be done with a reasonable effort nowadays. There may be rare exceptions but that did not happen lately.

So I would not call them hotfixes but just regular fixes. I my mind a "hotfix" is a hack that is justified by exceptional circumstances but that did not happen in a long time. There has been serious regressions in the earl v7.0 releases but even then workarounds were documented until a proper fix could land.

> What if we notice that an upcoming feature is basically unusable in the current form or needs serious improvement. It is reverted in the v8.0 branch and pushed to the next release. Such revert could be difficult in theory. In practice I'm quite sure it will be trivial for v8.0. > Will it allow hotfixes that require manual testing, for example, even after the deadline? In the current state of things there are bug fixes in the UI that cannot have automated testing at all because the infrastructure is just not there. Everything that involves JS & CSS is pretty much in this state and require manual testing. Automated testing in all other areas, including templates changes, can be done with a reasonable effort nowadays. There may be rare exceptions but that did not happen lately. So I would not call them hotfixes but just regular fixes. I my mind a "hotfix" is a hack that is justified by exceptional circumstances but that did not happen in a long time. There has been serious regressions in the earl v7.0 releases but even then workarounds were documented until a proper fix could land.

earl-warren commented 2024年06月25日 10:33:02 +02:00

To take into account the last two messages, here is what I propose:

Have two freeze periods:

• 26 June => no merge that require manual testing (with the exception of CSS / JavaScript bug fixes)
• 1 July => no merge that introduce a new feature

What do you think?

To take into account the last two messages, here is what I propose: Have **two** freeze periods: * 26 June => no merge that require manual testing (with the exception of CSS / JavaScript bug fixes) * 1 July => no merge that introduce a new feature What do you think?

earl-warren commented 2024年06月29日 07:05:53 +02:00

Before making another semantic release, I think it would be important to agree on what breaking changes mean: forgejo/governance#124 (all inputs have been taken into account, but not many people reacted/commented).

I will assume this is a question that does not raise a concern regarding the proposed feature freeze release date. Please comment if I misunderstood.

> Before making another semantic release, I think it would be important to agree on what breaking changes mean: https://codeberg.org/forgejo/governance/issues/124 (all inputs have been taken into account, but not many people reacted/commented). I will assume this is a question that does not raise a concern regarding the proposed feature freeze release date. Please comment if I misunderstood.

earl-warren commented 2024年06月29日 07:08:25 +02:00

To take into account the last two messages, here is what I propose:

Have two freeze periods:

• 26 June => no merge that require manual testing (with the exception of CSS / JavaScript bug fixes)
• 1 July => no merge that introduce a new feature

What do you think?

@fnetX as a few days passed this idea is no longer applicable.

> To take into account the last two messages, here is what I propose: > > Have **two** freeze periods: > > * 26 June => no merge that require manual testing (with the exception of CSS / JavaScript bug fixes) > * 1 July => no merge that introduce a new feature > > What do you think? @fnetX as a few days passed this idea is no longer applicable.

earl-warren commented 2024年06月30日 10:12:48 +02:00

The feature freeze will happen tomorrow because there only is two weeks to the release and postponing it further would have undesirable side effects. This discussion brought a few important points to light and I proposed to improve how feature freeze are handled in a separate discussion #187.

The feature freeze will happen tomorrow because there only is two weeks to the release and postponing it further would have undesirable side effects. This discussion brought a few important points to light and I proposed to improve how feature freeze are handled in a separate discussion https://codeberg.org/forgejo/discussions/issues/187.