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:
1.20 Dev Start
1.20 Half Way Point
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?
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.
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.
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?