As devchat reached the top of the hour last week, @youknowriad posted his comment about the gap between Gutenberg feature updates and Core major releases.
By December 11, Gutenberg will be ahead of Core with about 5 releases and this is a problem. 12 Gutenberg releases shipped into 5.3 . This is too much for a single WordPress release and with the current schedule, it’s seems like this is going to be similar for 5.4… This is not tenable for the future. It’s hard to stabilize and ship, it’s hard to summarize the changes for third-party developers and users, it’s more scary to ship and people were recommending the plugin to be installed for their clients (and it’s risky since the plugin is a development plugin). So how to reduce that gap is a big issue that needs solving IMO.Ideally I do think a shorter release cycle for majors is better. (Why not just a 5.4 in like end of January 😇 ), otherwise we’ll have to include enhancements in minors.
Riad also left this passage as a comment on @francina’s tentative release schedule, sparking a lively discussion.
So why bring up the subject here, separately?
There’s another question we need to answer, one that lies behind all of our discussions of schedules and cadences and majors and minors and who staffs what. To paraphrase @mapk, at about three minutes past the top of the hour on Wednesday:
What makes a major release?
The rule up to now, bent slightly in the year leading up to 5.0, is that we do not introduce new features in a minor, and really no enhancements either, no matter how small. Minors are for bug fixes and security only.
But then we wind up holding every single enhancement, big or small, for the next major. For some things, that hold can feel like a long wait.
That’s one of the circumstances that has led to the ever-widening gap between the Gutenberg plugin and the Core block editor.
Traditionally, as @azaozz pointed out, we don’t add new files in a minor because there is some potential for mishaps in the autoupdate process. He also pointed out that’s a technical limitation, already partly solved with our bump in PHP version support.
In response, @nerrad suggested that adding new files could become a lot less risky if WordPress moves to updated tooling like Composer, which is on the table in other conversations.
So now, per @mapk and the gang, we’re freer to ask the question based more on what users and devs would like to see:
What’s the bare minimum we can put in a release and call it a major?
And when we answer that, we can discuss any number of possibilities.
In the hour after devchat last Wednesday, and in the insightful commentary around @francina‘s 2020-21 roadmap, we can see ideas from monthly in-between-major-and-minors that just release new Gutenberg features, to starting four majors a year in 2020 and picking up the pace from there.
Chances are, dear reader, that if you’ve read this far you have thoughts of your own. Let’s hear them!
If you’d like to keep the trains of thought straight, I suggest we discuss what components, features and files go in what sort of release here, and scheduling, staffing and tooling over on @francina’s post.
Or we can just see what develops in both places.
Either way, whether you’re celebrating holidays this week or not, have a great rest of your week and a happy day Thursday!
Again, the tentative schedule is here.
The second part of devchat is here.
#2020-scheduling, #devchat, #releases
