Legacy class path for gracefully deprecating libraries. #947
Conversation
|
Build triggered by changes to the head. Unit testing complete. There were 13 failures and 40 errors from 2199 tests and 4120 assertions. |
|
Does that mean that the cms folder in the cms will also have to be renamed to legacy from 3.0 on? |
|
Does that mean we can safely think about letting the CMS 2.5.x series use the 12.x platform? That would be awesome. |
|
excellent move - literally :-) @infograf768 I'd guess for the CMS we might end up with three. One applying to real Platform-only "legacy" code, i.e. for BC with 11.x (PHP 5.2.x), and one for what's been invented for and introducted by the "/cms". |
|
The CMS libraries that are just for the CMS would go into the cms folder, that's exactly right. But skip having to track what to migrate or not and duplications. |
|
This is great. The aircraft carrier CMS really needs time for its stately manuevers. Could something built on the platform without the legacy layer loaded have problems if the legacy layer were to be loaded? Or could you mix legacy and non-legacy applications? |
|
@andreatarr, I don't think there is a singular answer to that question. I would imagine that certainly applications could be written in such a way as to use the platform with the legacy libraries or not, but in some cases it may not work. The obvious example to me would be something like reworking our MVC classes. Most of us would agree that there needs to be a bit of a rethink of some of those things, and I know that some preliminary work has gone into that by several parties. Obviously we'd want to have as much API compatibility as possible, but sometimes you just have to make a breaking change for the sake of a better solution. If that were to happen then (for example) the JController class and children as we know them would live in the legacy tree, and the new JController class would live in the standard platform tree. It's hard to know how easy or hard it would be to write code to work with either depending upon the situation without knowing the specifics of the differences. |
|
Louis - I am a bit confused on this so I hope you don't mind my questions. Wasn't the split put in place in part to build a cushion between the platform and the CMS so that the platform team could accelerate changes and cushion the CMS from the rate of change? I had understood that the CMS would select a platform version to use for the N.0 release and stick with it for 18 months. That would ensure the API only changes in N.0 and provide stability for CMS users and developers. Would it be possible to mark that release for all who want a platform release with long term support (3 years in total) knowing it would only have significant bug and security fixes? To me, that would take care of a lot of issues and free things up for the platform team to accelerate change and break whatever needs rebuilt -- but keep things nice and stable for production use. |
|
@AmyStephen, I never mind questions so long as the discussion doesn't devolve into pointless bickering and posturing. That said, your questions are great. You are correct in your assertion with respect to why the split was put in place, and my goals around it. The expected process for the CMS (or any downstream application) is as you suggest, to select a platform version for a given release and stick to it. Whether or not the CMS project wants to update that within STS releases is entirely up to them. Truth be told this change is as much for us as a platform team as it is for downstream users. We want to be able to move forward quickly. We also want to maintain as much backward compatibility and change management as is reasonable. We won't always succeed in making people happy, but we can strive to be thoughtful and considerate to as many users/developers as possible. I believe this will allow us to live up to our own expectations around backward compatibility while enabling us to really make innovative and impactful improvements to the platform. Simply, it's a little breathing room. I personally am not at all supportive of the platform maintaining long term support for versions. I think (at least for me) it is counter to what I want to drive with the platform. That being said, downstream projects could provide that level of support and we'd certainly try to be helpful in situations where its needed. Hopefully that answers your questions. |
|
I think this is way better than an LTS version and more like what is seen in other frameworks, really good tolerant support that respects the fact that application development has different needs than library development. |
|
@AmyStephen great questions. The LTS versions are fine, there's no problem there and they should most definitely lock into a version of the platform. The problem we have is we want to make some breaking improvements/changes in 12.1 that are fine for the platform, but would cause harm to Joomla 3.0 if it chose to upgrade (every extension developer could have to rewrite their MVC since it's on the list for a major overhaul - probably not an easy sell). So what we are doing is adding a second cushion for the 2.5 -> 3.0 scenario's. Another way to look at it is we are providing a two-stage deprecation strategy. The platform purists get to work with the latest and greatest code and upgrade frequently. Downstream users building aircraft carriers, as Andy puts it so well, have the chance to buffer the fast-track changes by using the legacy tree. Eventually "stuff" would be completely removed from even the legacy tree, but that can be done now at a more leisurely pace and those using the legacy tree can call the shots on that. There is also no reason why bugs can't be fixed in the legacy tree by those that need them fixed. But keeping the platform still as one package means that, for example, Joomla 3.0 can maintain B/C via the legacy tree (and still have it's own /cms/ tree to boot), but still take advantage of new work like JCrypt or other API that has maintained full B/C (like the database refactor) etc. I think it's the best of all worlds really. |
|
AND you can have those bleeding edge applications running right next to the CMS without having to have a second complete copy. |
|
Seems like a reasonable approach. +1 |
|
Thanks @LouisLandry and @eddieajau for those responses. You've got my full support to break whatever needs rebuilding in the framework -- I believe in what you are doing. The CMS team plays such a critical role in building support for the work the platform team is doing by demonstrating that the mission is one of stability and that the CMS is not trying to keep pace with the platform. My sense was a "specifically numbered release" might more clearly send that message and help the CMS not 'feel the pressure' of exposing new platform capabilities, but if this is the best way to buy room for improvements, then so be it. |
* Create a new import.legacy.php for bootstrapping the platform with legacy library support. * Removed legacy and deprecated lines from the standard import.php bootstrap file.
* Move JProfiler to its own package.
* Move JApplication to the legacy tree. JApplicationWeb, JApplicationCli, JApplicationBase should be used instead. Interface to follow. * Move JApplicationHelper to the legacy tree. * Move JCategories to the legacy tree. * Move JMenu to the legacy tree. * Move JPathway to the legacy tree.
|
Build triggered by changes to the head. Unit testing complete. There were 0 failures and 0 errors from 2193 tests and 11591 assertions. |
Legacy class path for gracefully deprecating libraries.
One the important questions about how to proceed with the separation of the CMS and Platform has been how the platform will remove libraries that are still depended on by the CMS (and other downstream projects) in a way that isn't overly disruptive. This pull requests takes a stab at answering that question.
The libraries formerly found in the
libraries/cmsfolder have been moved to a newlibraries/legacyfolder. Additionally there is a notlibraries/import.legacy.phpfile. In order to bootstrap the platform with legacy classes you simply includelibraries/import.legacy.php. If you want to bootstrap the platform with only the latest and greatest and no legacy class support, continue includinglibraries/import.phpas always.This allows for a more graceful exiting of deprecated classes, and a path for modifying existing classes in a way that creates some hard breakages while still retaining legacy behavior if an application needs it. The solution simply relies on the autoloader and the order in which it searches for files.
If the legacy import file was loaded then the autoloader will always look for a class by name first in the legacy path, then fall back to the main library path. If the regular import file was loaded then the autoloader ignores the legacy tree altogether.
Along with this pull request I also moved some CMS specific and deprecated classes into the legacy tree and modified the test suites so that everything runs successfully.