#ee3 What are the plans for the legacy folder?
Developer Preview
How long is that going to stick around? After looking things over a bit I’m debating on how to progress with my add-on upgrades…
1) Make minimal changes because legacy exists. Live with less than ideal code for now and until an undetermined time. These changes may make the same codebase work in EE 2 and EE 3 at the same time.
2) Fork my codebase and start using all the new features in EE 3. Pain in the ass for support though.
3) Ignore the new service container and continue using Pimple instead. Refactor most of the add-on so it will work with EE 2 and EE 3 as long as legacy exists, and convert the rest of it when legacy goes away.
Are there any plans to make the service container backward compatible? For example could I use it in EE 2 for my add-on code, e.g. ee(‘Publisher/SomeService’). That way I can start converting things to EE 3 compatible code and still have everything work in EE 2 and EE 3 with the same codebase. This could be something added to EE 2.11.
Basically I’m still trying to figure out the best way to approach this upgrade…
Thought of a jank way to maybe work around this…
ee()->publisherContainer['Notification'] = ee()->publisherContainer->factory(function ($c) {
return new Publisher\Service\Notification();
});
// Persistent Singleton
ee()->publisherContainer['RequestCache'] = new Publisher\Service\RequestCache();
if (!function_exists('bm')) {
function bm($service = null) {
if ($service) {
$service = str_replace('Publisher/', '', $service);
return ee()->publisherContainer->getService($service);
}
return null;
}
}Then use it as
bm('Publisher/RequestCache')->setParam('foo', 'bar');Later on I should just be able to find/replace bm( with ee( and everything should theoretically work so long as the service definitions are updated.
Brian, if it were me—and of course this is based both on what I’d prefer to see but also based on my observations of what happened with some moving from 1 to 2—I’d follow the lead of eecms itself. New repo for your 3.0 compat add-on, and no new features for your 2.x one. Support can be limited to bug fixes for a year, and where it impacts both versions just duplicate the fix. Keeps everything separate and clean, work on the old one is minimal, and you don’t put yourself in a position to be stuck with old code long after the cow is put out to pasture.
The entire ecosystem benefits from people pushing forward.
What about the lifetime of that legacy folder?
Per SemVer, it will not be a moving target during 3.x. We know that caused major issues for everyone in 2.x until we adopted SemVer. So anything you see there now you can count on working consistently throughout the life of 3.x, even if we add a replacement and deprecate the legacy lib during 3.x. Breaking changes would mean a 4.0 release.
The documentation there will improve to be clear about that over the course of the DP as we start working on those areas.
Does that answer your question? I want to make sure I’m answering the right thing for you.
Yes it does, thanks!