Summary of Changes

The social packages that ship with the CMS that are also part of the Framework stack are for the most part duplicated code with feature parity and as such there really isn't a need to maintain two versions of almost 100% identical code. Unfortunately, we can't just simply proxy these packages over as was done with JRegistry because the underlying HTTP adapter code has some structural differences in favor of configuration injection versus reading from something like JFactory::getConfig(), however feature parity can be achieved as CMS 4.0 and Framework 2.0 are released making it easier to easily use the same code/features from one source.

Therefore, I propose to start deprecating the social packages as they exist in the CMS today with the plan to remove them in 4.0. This also in theory enables the CMS to NOT ship these packages in 4.0 in favor of developers pulling them as dependencies in their workspaces and packaging things up themselves, or just simply shipping the Framework versions of these packages (if they continue to exist). As with all of our existing libraries extensions though, and any extensions which may have integrated a Composer based workflow into their systems, the infrastructure for that would need to be better defined in the CMS APIs. Nonetheless that shouldn't be a showstopper to this being reviewed.

Testing Instructions

Maintainer decision

Documentation Changes Required

N/A, this package is not documented in the CMS workspace