Foreman 3.9 branched on 2023-11-21. We add 3 months of development time to that, so we end up with 2024-02-20 as the branching date with GA following 4 weeks later on 2024-03-19.
Working our way backwards from GA. As always, there are 2 release candidates prior to GA with 2 weeks between them. That’s preceded by branching (same day as RC1) and a week of stabilization. Installer modules should be done the week before stabilization.
Filling in the table it gives us the following schedule:
| Event | Date |
|---|---|
| Dev start | 2023-11-22 |
| Half way point | 2024-01-06 |
| Installer module release week | 2024-02-05 - 2024-02-10 |
| Stabilization week | 2024-02-12 - 2024-02-17 |
| Branching | 2024-02-20 |
| Release Candidate 1 | 2024-02-20 |
| Release Candidate 2 | 2024-03-05 |
| General Availability | 2024-03-19 |
Copying guidance from Foreman 3.9 Schedule and Planning these are the things to keep in mind:
- Stabilization week is to ensure we have working nightlies when branching happens. This should also be the considered the string freeze period, to give translators sufficient time.
- Larger changes should be merged as early as possible in the release cycle, to ensure enough time to fix bugs prior to branching.
- Keep in mind that installer module changes should also be merged prior to the stabilization week.
- As we near the branching date, we shall ask your cooperation in focusing more on stabilizing and bug fixing and less on new features.
- If you have a significant change that you wish to get into 3.10, request to set the “Target Version” field on Redmine at least for the main tracker for the bug. We also request maintainers to make sure that when merged, any major features are added to the “highlighted features” section on the manual, and any deprecation or changes in behavior are also added to the relevant sections (Foreman and Katello ). If you wish to discuss any plans, this post’s comments can and should be used for that.