RFC: Sync Foreman and Katello versioning, and reset both to 5.0 at full EL9 support

Hi everyone.

As a member of the user community I would like to propose this idea which has been probably discussed before, it is time to sync the Foreman and Katello versioning.

There is now a Katello release that corresponds to every Foreman release, they just don’t match version numbers.

I believe it is getting close to a good time and good excuse to do this.

I propose that when it comes time to declare Foreman as supporting running on EL9, that then everything is moved to 5.0.

Then from then on, Katello 5.X.y will always go with Foreman 5.X.z.

This would allow them to have separate minor releases/updates if that is still desired, but make it much clearer and logical what goes with what., eg Foreman 5.2.1, and Katello 5.2.3.

Anyone have any further thoughts?

3 Likes

Interestingly, we discussed something similar, but not quite the same in the Infrastructure meeting today:

TL;DR: we want to re-structure the repos in a way that while katello will retain its own versioning, you will get the “correct” katello by fetching foreman/X.Y/katello repo (and foreman will be foreman/X.Y/foreman, and plugins foreman/X.Y/plugins).

Would that suit your proposal too?

I’d be more in favor of restructuring the repositories in that way to allow for more flexibility. You generally don’t care about the version of REX that we include in the repositories, you just want the version that we recommend with Foreman x.y. In general I think we’re moving more in a direction of making Katello just “a” plugin, rather than making it more special than it already is. You can see that in the release workflows where we’re restructuring things and the above proposal is another step.

2 Likes

There have been quite a few requests like this over the years, on a quick search I could find two more:

Though, I can remember at least one or two more I have personally seen over the years.
The usual reasoning behind these requests is “it is confusing”, which I absolutely agree with. We rarely see anything remotely similar for other plugins, because people just grab “foreman-plugins-X.Y” and everything works. Restructuring the repos should definitely help, and maybe reorganization of the docs to also simply refer to the Foreman version might help even more.

1 Like

I like the idea of dropping the Katello version from the navigation in https://docs.theforeman.org/ and only show Foreman versions. Would people accept this?

In other words, it becomes Foreman X.Y with Katello instead of Foreman X.Y & Katello A.B.

3 Likes

These all sound like a step in the right direction. I have seen discussions about making Katello “just another plugin”. But I can tell you the reality right now is we heavy users of Katello, track and plan around Katello releases just as much or maybe more than we do Foreman.

So probably one thing that would have to change with this plan, is that whenever there is a Katello release, it would trigger a new release of Foreman.

So if we just start calling everything Foreman X.Y, and Katello needs to then do a update/release, it should trigger Foreman to release X.Y.Z+1 with the Katello updates, just as it would for something else that had to be updated inside the Foreman core today which causes Foreman minor releases to be created.

This will possibly increase the amount of Foreman minor releases since today, Katello can do a release separately without having to trigger an incremental Foreman release, but it will I think be better and clearer to community long term.

I fail to understand why you want that. It’s a lot of additional work on the release team and we’re working in the opposite direction. We want Katello to have a workflow where they can easily release bugfixes.

What you are proposing would introduce so much additional work that I suspect the end result is fewer releases, meaning bugfixes probably won’t be backported to stable releases as much anymore. Because of that I think it will be worse for the community in the long term.