Hello all -
Katello 3.10 will be branching November 29th (updated from the 20th), to align with the release of Foreman 1.20
| Event | Date |
|---|---|
| 3.10 Feature Freeze | November 12th |
| 3.10 Branch Date | November 29th |
| 3.10 Release | December 17th |
3.10 will add in errata applicability with modules, Pulp 2.18 integration, support for Subscription-Manager unified reports, and any bugs found by QE/community.
There is a Release sub-category within Development I would recommend sending this and future updates to.
moved it
Given this release will be tied to the Foreman 1.20 stream and the first of it’s kind for Katello, there are a few considerations that are needed by Katello devs.
The alternatives to the above are to change nothing, hope the time frame is short enough and post branch test and see if anything is incompatible with 1.20.
[ehelms] ehelms https://community.theforeman.org/u/ehelms Leader
October 18Given this release will be tied to the Foreman 1.20 stream and the
first of it’s kind for Katello, there are a few considerations that
are needed by Katello devs.
- Katello PRs currently test against develop, do you want these
switched to test against 1.20-stable branch?
Could we do both?
- Foreman PRs are tested against Katello master, there is a
possibility Foreman core may introduce a breaking change in
develop branch before 3.10 is branched- Katello nightly pipelines run against Foreman develop but given
3.10 is against 1.20, do we want to change these for the duration?The alternatives to the above are to change nothing, hope the time
frame is short enough and post branch test and see if anything is
incompatible with 1.20.
For these two i don’t have great answers, nor think going one way is one
better than another. Ideally we could keep this 3.10 branch working
against both releases, even if we only release against 1.20. I could
see this possibly involving gated checks for the foreman version, which
i would be okay with if we remove them after 1.10 branches. I don’t
know how practical that will be over the course of the month though.
Maybe I missed something but this skips a Foreman release, correct? What’s the reasoning behind this?
I thought 3.11 would be against 1.21, is that not the case?
We have 1.20/3.9:
This suggests we’ll have 1.20/3.10 where I’d expect 1.20/3.11.
IIUC, the plan is to have 2 katello releases that will be compatible with Foreman 1.20: 3.9, which will come out at the same time as 1.20, and 3.10 which will come out about a month later with some extra features mentioned above. 3.11 will resume releasing in concurrency with foreman (1.21, in that case).
Ah, so I did miss something in my understanding. This does make sense.
It does make me wonder if we need forklift boxes named centos7-katello-1.20-3.10 and centos7-katello-1.21-3.10 to test both.
Do you mean centos7-katello-1.20-3.9 and centos7-katello-1.20-3.10? My understanding is:
1.20 + 3.9 (as usual)
1.20 + 3.10 (additional katello release, same foreman)
1.21 + 3.11 (back to the usual way)
Yes. This will increase burden and potentially time for each PR. The question devs will need to ask themselves is what to do when one or the other breaks for any given change.