[wp-trac] [WordPress Trac] #47837: Proposal: Componentized Upgrades

[WordPress Trac]

#47837: Proposal: Componentized Upgrades
--------------------------+------------------------------------------------
 Reporter:  mdwolinski    |      Owner:  (none)
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:                |    Version:
  Upgrade/Install         |
 Severity:  normal        |   Keywords:  dev-feedback needs-design-feedback
  Focuses:                |
--------------------------+------------------------------------------------
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47837>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform