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

There is something very good about the fixed date release schedule: everyone knows it is coming and can plan accordingly. It would otherwise require negotiations about the release date. And negotiations about why the release should be delayed. Or why it should be fast tracked. It saves valuable time and energy.

I propose, based on this week discussions that the feature freeze period is set to be three weeks before the release. Two weeks is a little too short. It would also be in sync with the monthly report as each feature freeze would happen the last week of the month and can be announced. If it happens right after the monthly report is published, that's a lost opportunity to draw attention to it.

---

Feature freeze

• Starts three weeks before the release date and is documented in the release schedule
• No feature / enhancement is merged.
• No merge that require manual testing, with the exception of CSS / JavaScript bug fixes when tests cannot be easily written

It is the responsibility of the release team to complete the following tasks:

• Release blockers are resolved.
• Manual tests are performed as documented in the corresponding pull request.
• New features are manually tested to work in a simple use case.

---

TODO:

• update the documentation https://forgejo.org/docs/v7.0/developer/release/#feature-freeze
• clarify that the branch must be cut at the date of the feature freeze

There is something very good about the [fixed date release schedule](https://forgejo.org/docs/next/developer/release/#release-cycle): everyone knows it is coming and can plan accordingly. It would otherwise require negotiations about the release date. And negotiations about why the release should be delayed. Or why it should be fast tracked. It saves valuable time and energy. I propose, based on [this week discussions](https://codeberg.org/forgejo/discussions/issues/180) that the feature freeze period is set to be three weeks before the release. Two weeks is a little too short. It would also be in sync with the monthly report as each feature freeze would happen the last week of the month and can be announced. If it happens right after the monthly report is published, that's a lost opportunity to draw attention to it. --- # Feature freeze * Starts three weeks before the release date and is documented in the [release schedule](https://forgejo.org/docs/next/developer/release/#release-cycle) * No feature / enhancement is merged. * No merge that require manual testing, with the exception of CSS / JavaScript bug fixes when tests cannot be easily written It is the responsibility of the release team to complete the following tasks: * Release blockers are resolved. * Manual tests are performed as documented in the corresponding pull request. * New features are manually tested to work in a simple use case. --- TODO: - [ ] update the documentation https://forgejo.org/docs/v7.0/developer/release/#feature-freeze - [ ] clarify that the branch must be cut at the date of the feature freeze

earl-warren commented 2024年06月30日 10:08:27 +02:00

@fnetX as a member of the User Research team, do you want to commit to perform user testing during this period, for each release? Or would you rather do it when time permits, depending on your availability?

@fnetX as a member of the User Research team, do you want to commit to perform user testing during this period, for each release? Or would you rather do it when time permits, depending on your availability?

fnetX commented 2024年06月30日 13:12:42 +02:00

I think I'd start with the more flexible option. As you can see, I did the user research, but now lack the time to finish up the notes.

I'm also thinking about different approaches with less manual effort on my side. I have some ideas.

I like the idea of a fixed release schedule combined with freeze periods. I'm still in favour of treating usability regressions such as forgejo/forgejo#4263 specially. They are not bugfixes, but they do address real problems that would lead to a decreased release quality.

I think I'd start with the more flexible option. As you can see, I did the user research, but now lack the time to finish up the notes. I'm also thinking about different approaches with less manual effort on my side. I have some ideas. I like the idea of a fixed release schedule combined with freeze periods. I'm still in favour of treating usability regressions such as https://codeberg.org/forgejo/forgejo/pulls/4263 specially. They are not bugfixes, but they do address real problems that would lead to a decreased release quality.

earl-warren commented 2024年06月30日 15:01:39 +02:00

Ok, there will be no promise regarding user testing in the release process.

Ok, there will be no promise regarding user testing in the release process.

fnetX commented 2024年06月30日 21:16:44 +02:00

If there is a workflow established over time, it can always be added then.

If there is a workflow established over time, it can always be added then.

earl-warren commented 2024年06月30日 21:28:18 +02:00

Exactly. It is not carved in stone. Subtracting is difficult. Adding is easy.

Exactly. It is not carved in stone. Subtracting is difficult. Adding is easy.

earl-warren commented 2024年07月15日 09:06:04 +02:00

Let's have the three weeks feature freeze then.

Let's have the three weeks feature freeze then.