On 20 May 2015 at 23:55, Michael Babker <> wrote:
> Right, but does the namespace of the interface then change too? So you
> could have \Joomla\Session\SessionInterface in the 1.x branch then
> \Joomla\Session\v2\SessionInterface in the 2.x branch. How are the two
> branches remotely compatible with one another then?
I don't think that's a good example because you physically can't
implement 2 sessions at the same time. But let's think about what we
can do "today" with Session.
Let's say we finalise \Joomla\Session@2.0. We want to add that to the
CMS and there are no dependency problems (which I'm sure there will be
Today we can add Session@2.0 to package.json
We can then migrate all the core code over to using it.
We have JSession implement the Session@2.0 interface.
We convert JSession to be a wrapper for the \Joomla\Session@2.0 code
and we mark JSession as deprecated.
One day, we decide we need a breaking change and the FW Team cuts Session@3.0.
The plan is to integrate that into the CMS for whatever reason.
Because of the way Session is used, that will introduce a breaking
change so the CMS must plan to bump to the next major version.
Now, let's say, however, that we upgrade the MVC packages
significantly (like they don't need some further decoupling) to v3.
Let's say the CMS is already using MVC@2.y and we have to assume some
custom sites are relying on the new interfaces.
For the CMS to upgrade to MVC@3.0 it needs to consider bumping its own
major version. But in this case, does it really need to?
If you can put MVC@2.y and MVC@3.0 beside each other, then we can have
core running on @3.0 but custom work is still using the @2.y version
of MVC and running quite happily thank you very much.
When the CMS does get around to bumping to the next major version, it
can drop MVC@2.y completely.
The question is how can we have those running side-by-side. I think
there are a number of options and I put to you that namespace is just
one option, but I also put to you that we can worry about that bridge
when we come to it. Making a deliberate decision to reform the CMS
architecture because we are the developers that should be doing it is
far more important.
> In truth, I think I can live with the hole we've dug ourselves into with 30+
> individual components going on 30 different paths as far as versioning goes,
> but only within a major branch. I don't think it'd do us a lot of good to
> have Database v3, Application v2, and Registry v4 all floating around as the
> "active" versions, that'll get confusing quickly (and yes I know that's
> really hypothetical but I hope it illustrates one of the things I dislike
> about a scenario that idea allows to happen).
No, the idea of having two versions of Application and even Database
is nonsensical. They run the show so you need a strategy like I
outlined for Session above. I would do the same for Registry, but I
think Registry is a good starting point to pick on for major code
> I'm speculating on the v4 CMS codebase. You're suggesting that the API be
> versioned via namespaces (which the only way to do this with Packagist is
> creating new packages for every major release because that and Composer
> won't let you install two versions of the same code),
At least it is today. We could talk to Jordi about way we could
potentially solve this problem via Composer.
> so in theory you open
> the door for a CMS extension running on a potential v4 of the CMS which is
> running the CMS v3 "legacy layer" and potentially uses Framework v1 code.
> Reading this, it's really confusing, but it makes sense in my head, I swear!
As I outlined, there are is a line in the sand as to what is practical
to version and what is practical to upgrade. Some packages are going
to be very close to that line, but I think there is enough work to be
done that it doesn't have to be hit for some time.
The reality is, if we invent a better Joomla Component paradigm,
developers are going to try and make their own bridging layers anyway,
and they never do it well and your CMS ends up polluted with 50
different kinds of MVC triad wrappers (and don't get me started on
template frameworks - what is happening now it absolutely nuts). So
it's better that the core set the standard for how old and new should
live together, and one day you just have to break things. My premise
is, however, that we can do a lot with 3.x with smoke and mirrors to
avoid the fear and uncertainty that surrounds the number 4.
> Of what's there today, the only package with a roadmap idea that may have
> B/C implications is splitting off the Registry package's loader classes to
> form some sort of abstract layer usable for different purposes (one idea
> floating around is adding support for more file formats in the Language
> package, which would serve the PHP community moreso than Joomla most
> likely). That also implies that no other Framework packages will get merged
> into the CMS for the remaining lifetime of its 3.x branch. If the Language
> package gets integrated back into the CMS, that one would have B/C
> implications going between major versions. And on the MVC side of things,
> the current v2 View package is a fair bit different than the previous
Bottom line is there needs to be a plan and some of the decisions made
to date may make it difficult to move forward in the best possible
way.However, if the FW Team is just doing it's own thing, there is no
point to be attached to the drama of the Joomla community. It would be
much better to leave. If one of the roles is to serve the CMS, then we
need a plan and the CMS needs to play ball as well. Given that George
is here, I don't see that as a problem.
I think, perhaps, Registry, Language and MVC would be good places to
start. Make sure they are SOLID and work up from there. A bigger
project is looking at how extensions themselves could be installed
with Composer and I think we'd need to invent a lot of the engine to
As far as the Team goes, however, I think we need to change the "do
your own thing" attitude and having most people working to solve the
same problem most of the time, or having the same short term goals
most of the time.
Does that make sense?
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.