[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Versioning namespaces



Conceptually, it makes sense and has merits.  Conceptually, the idea solves a major problem that we ourselves created due to poor change management and decision making.  It's the execution I'm not confident in, or the idea to redefine PHP standards (building an environment where multiple versions of a software package could be included in a single application).

I see conflicting visions in how the software is developed.  We want to move toward a modular application environment where each API component can take on a destiny of its own.  In that vision, I see a collection of 30+ individual and isolated components doing their own thing and loosely grouped under a single brand.  Not one component has been changed to take advantage of our own dependency injection code; is our aim very loosely coupled packages full of good ideas or to provide a strong application framework to build upon?  We also want to build the next generation of the application our brand is known for using these modular and independent moving components.  In an environment where historically we can't decide whether to meet for lunch tomorrow or not.  So I have concerns that we (as a whole) could execute any plan that calls for several independent moving pieces to come together to form a single application framework, without taking into consideration that those components could potentially be restructured in a way that multiple versions of them could conceivably be run in parallel.

If I take my developer hat off and look at this idea as an end user, I see "that's amazing" written all over it; upgrading to the next major of the version is nowhere near as painful as before and I don't even need to be concerned my extensions aren't natively compatible, they'll just work.  So yes, for the 99%, it's a good idea that should be followed through on.

For the 1%, those people getting their hands dirty producing the product and the extensions that makes Joomla's ecosystem function, it's a hit-or-miss thing.  On one hand, devs won't have to update their extension code anytime soon (and even if the CMS dropped compatibility for something, the extension should be able to include that code on its own anyway by that point, so no big deal for them).  On the other hand, it would destroy any possibility of majorly overhauling and modernizing the application because the CMS would be burdened with ensuring that somehow, a subset of APIs still work as advertised.  As far as the code structure goes, my worst case scenario vision is a platform with so much spaghetti code that it makes WordPress' PHP code look beautiful.

I don't know the right way forward.  But in my heart, a proposal that versions the API via class names or creates a need for separate packages per major branch does not feel right, even if it aims to solve our own problems.

On Wed, May 20, 2015 at 6:27 PM, Andrew Eddie <mamboblue AT gmail.com> wrote:
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
to solve).

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
reform.

> 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
> version.

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
do that.

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?

Regards,
Andrew Eddie

--
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.

--
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.