1.20 Planning


With 1.19 branched, it’s time to start looking at the 1.20 schedule and roadmap.

1.20 branching will be October 16th, 3 months from the 1.19 branching. Refraining from merging significant changes in the days leading up to the release seems to have had a positive impact and I would like to continue with this and perhaps even improve on it.
One idea that has been brought up is to try and do a test week on nightlies before the branching instead of doing it at the RC stage, since fixing issues in RCs is a bit more difficult compared to develop. This means that the week leading up to branching will be a stabilization week with no major features being merged during that time, meaning hopefully the RC cycle will also be faster as bugs will be caught earlier. I would be happy to hear other people’s feedback regarding this idea.
In any case, this means that any features planned for 1.20 should be merged by October 8th. So the planned schedule should look something like this:

Event Date
1.20 Dev Start July 16th
1.20 Half Way Point August 30th
1.20 Stabilization October 8th
1.20 Branch October 1617th
1.20 RC1 October 19th23rd
1.20 RC2 November 1st
1.20.0 November 18th

To try and plan a bit ahead, I’ve put down a list of some of the more significant feature that are aimed for this release afaik. I’ll make this post a wiki so others can add other features to the list. Please keep in mind this isn’t a commitment that these will all be in the release, but more of an attempt to collaborate on what we are aiming for and prioritize these features.

Planned Features for Foreman 1.20 (Please add others you think should be in):

  • Rails 5.2 upgrade
  • Drop support for puppet <4.x
  • Report Templates
  • Canned admin role
  • New Audit UI
  • Upgrade procedure
  • Improve Rails logging stack - tagging
  • Dedicated Foreman client repositories
  • Foreman plugins that closely follow the same schedule (Please add others you think should be in):

    Katello 3.9
    1 Like

    Thanks for bringing this up. I like the idea of testing before RC. I also
    like sharing of features being worked on for the release. I’ll add few
    things when I get to my computer. Since we know dates now, could we add
    them to community calendar?

    I think it would be nice to lay the dates out here too for a secondary reference. Something as simple as:

    Event Date
    1.19 Dev Start July 16th
    1.19 Half Way Point August 30th
    1.19 Stabilization October 2nd
    1.19 Branch October 16th
    1.19 RC1 October 19th

    There are a few RFCs open. It’d be good to decide which ones should make it in. Personally I really want the capabilities and installer merge to happen.

    1 Like

    That looks good, only the version number is wrong :slight_smile: I’ll add that on the top of the wiki

    That seems like a good idea. Most of us (TL2+) have rights to create events on the calendar. I’d suggest a tag of some kind so they can be filtered on…

    Is this thread solely for foreman or may features from plugins like katello be added?

    The ecosystem not just Foreman core. I would suggest plugin authors add a section so it’s clear the issues are for their plugin in the pinned thread.

    On the other hand, here we are talking about the planning of Foreman 1.20 features. Plugins have their own release cycles. Unless the branching happens at the same time I’m not sure if it should be included here.

    1 Like

    Since each plugin has its own release schedule and process, I think it makes sense to open separate threads for every plugin that wishes to share their schedule and plans.

    Personally, I’d find that more difficult to figure out the ecosystem unless we had a release category in discourse to limit things down to. But I am also looking at this from the perspective of plugins that tend to release in cadence or roughly in cadence.

    That’s actually a good idea. I made a releases category so we can put all of these threads in there instead of in the generic development category

    1 Like

    I know that last two times when I suggested this I failed, but can’t help myself.

    Do we want to bump the version to 2.0 for smaller numbers? Again, my suggestion is for nothing, because IMHO if we start discussion which features are good candidates for major version change we won’t agree on anything and status quo will continue.

    Why so many open-source project hesitate to bump major versions? Well, except Firefox and Chrome. It’s encoded in us that major version change must be huge. Vast majority of our releases were evolution, not revolution. Maybe it’s good time to start versioning scheme discussion, I would actually like calendar-based scheme since our cadence is fast and predictable for several years now.


    I think it might be good idea to list plugins and their target version here too. At least those whose maintainers want to have version branches compatible with given Foreman branch. E.g. I know that foreman_ansible for 1.20 will most likely be 3.0 and will contain ansible variables feature. I know we can always find out the list of compatible version ex-post through what we have in repos, but I think it wouldn’t be too much data and it might be good to have a list of plugin version generally compatible with the upcoming release.

    Would it make sense to have the 1.20 Stabilization align to the end of a sprint? Many of the dev teams are currently working towards the same sprint schedule.

    Below are the 2 sprints that are around the current Stabilization date:

    • sprint 39 : 2018-10-02
    • sprint 40 : 2018-10-22

    It could be a good idea to dedicate sprint 40 (assuming that’s the end date) to stabilization and testing of 1.20, if the various development teams agree to do that.

    It’s not encoded in us, but rather in semantic versioning (https://semver.org/). I don’t see anything inherently wrong with having 1.57079 if needed. We follow it nicely so that once plugins have breaking changes (incompatibility with Foreman old versions for example), they bump their major version.

    I would advocate for bumping the major version once API v2 can be retired, for example, or upgrades break the workflow/automation scripts a lot.


    Based on the replies above, I’d like to suggest that the pinned post be allowed to be edited for plugins that branch in sync with foreman. Specifically katello, but also any of the other foundational plugins that also follow that cadence.

    Feature leads would be responsible for updating their section of any plugin with relevant PRs (or redmine issues?) for highlighting the work.

    I personally really like this all-in-one-place post that may be easily referenced. Thanks for putting it together @tbrisker


    I tend to agree with Tom. It was also suggested by Eric and Marek.

    While it isn’t true for all plugins, there are a set of core plugins that follow closely and align with the foreman core release. In order to ensure that all are working together closely and towards the same goal, it seems reasonable that we’d have a single place to define the overall milestones and high-level plans.

    I think this thread is an enormous step forward. Thanks for initiating it @tbrisker.

    Is it permitted for plugin owners and feature leads to add sections to the above wiki?