Proposal: Componentized Upgrades

[mdwolinski]

Recently there has been some talk about the cadence of updates for components of WordPress compared to the core updates. The current practice is that new functionality is added into subversions (5.1, 5.2, etc) and only bug fixes are in minor versions (5.2.1, 5.2.2, etc).

However there are components that are having releases quicker then core, meaning that users may not see additional functionality until the next version release, which can be months away. This proposal, at a high level, is intended to propose a solution that allows for a user to update components outside of the core updates.

Mockup

Important: this is just a concept mockup for discussion purposes to highlight some of the functionality.

Accessibility Note

The mockup above and the functionality described below is most likely not the ideal way to implement the functionality in a completely accessible way. Those who are more knowledgable on the subject should be consulted to modify the functionality in a way that works for all users.

Functionality

The main concept is to have the ability to update components independently from core if they become available. The mockup above represents a timeline between the currently installed version of Core (v5.2.2 above) and the currently planned version (v5.3).

The WordPress Core line, by default is collapsed and would not show the components below it. This would then function as the current upgrade functionality does and update all components at the same time. Expanded, this allows the user to upgrade individual components as they wish.

In the mockup:

• Black Dots indicate the current installed version for Core and components.
• Green Dots are versions available to install.
• Red Dots are unavailable to install (see more below).
• Yellow Dots are next versions in development with estimated release schedule.
• Red Line Current Day.
• Dotted Line future.
• Solid Line past.

Reading The Version State

The user has the Wordpress Core, Customizer, Site Health, and Passwords installed at v5.2.2. They have 4 newer versions of Gutenberg installed and one newer version of the Rest API installed.

If the user upgraded Core to v5.2.3, it would update all components to that point, meaning that Core defines the minimum version for all components.

On the Gutenberg line, for example, the user has a version installed and can, if they wish, go back up to two versions (two grey dots), however, because of an update change in the version + 2 (first grey dot), they are unable to back port the version before that (two red dots). Perhaps a DB change or something. The user can, however, upgrade an additional version (which was released the same day at v5.2.3 core) but the next newer version requires core to be at v5.2.3 so it is unavailable to update (or another reason, who knows).

The Site Health component is unable to be updated because it might require the newer version of Rest API as an example.

Hovering or clicking on the dots allows the user (either via popup, tool tip or another means) to see details on that release, upgrade to it if available, and link to release notes. On future releases (yellow dots), the information can show the estimated release date, etc.

Expanded Plugin Support

The concept above could also be expanded to third-party plug-ins and themes.

Integration with Site Health could be included as well, for example, if 5.2.4 required a newer version of PHP then is currently installed, the dot for it would go red and allow the user to see what is blocking the upgrade to it before the release of it.

[mdwolinski]

Component Upgrade Mockup

[audrasjb]

Hello and welcome to WordPress Trac!

There is a lot of great ideas in this proposal. One thing is quite certain in my opinion: before having such a (big) feature in WordPress Admin, the proposed workflow has to happen in WordPress core development processes itself. This is not the case today, since releases focuses are not that detailed, even few weeks/months before the release date.

(by the way, it already makes sense in Gutenberg development workflow)

/following the ticket to see where this will leads us :)

[mdwolinski]

@audrasjb Agreed, I don't see this as a 5.x feature. The Gutenberg project is part of the inspiration for this and since new features should be developed as plug-ins first, seems like the kind of model this would work work, ie the above could just be grouping any "core" plugins (ie the Gutenberg developer plugin) together. Other components I listed I just took from the different slack channels and would of course need to be separated out for independent releases (if possible).

This is certainly a need for much more discussion and planning on the workflow as you mentioned before implementation could even start.

[paaljoachim]

The ticket was brought up during a design triage.
We feel that it is too complex and from what we see we would lean more toward having the update feature in a (if possible) plugin. It though involves various aspects of components for core. So this can be a bit tricky.