As devchat reached the top of the hour last week, @youknowriad posted his comment about the gap between Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ feature updates and Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.?
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 A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and security only.
But then we wind up holding every single enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., 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 Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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, #dev-chat, #releases