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):
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?
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.
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…
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.
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.
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:
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?
I’ll add that on the top of the wiki