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

Re: [jfw] Versioning namespaces

On 21 May 2015 at 09:24, Michael Babker <michael.babker AT gmail.com> wrote:
> 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).

PHP does it, just not in the same way (compare functional and OOP
versions of Array handling API).

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

I think that was a fatal mistake and it's led to the chasm between the
CMS team and the FW team. And as I say, if that's the case, there are
better brands than Joomla to be under.

> Not one component has been changed to take advantage
> of our own dependency injection code;

That's a chicken and egg problem. But on that point, DI is very easy
to abuse so let's chalk that up to a good thing that they haven't
developed any bad habits yet.

> is our aim very loosely coupled
> packages full of good ideas or to provide a strong application framework to
> build upon?

I cannot say this enough. Like it or not, the Joomla brand means CMS.
If this Team is a framework club, ditch the Joomla brand and align
with Phil Sturgeon or someone else. At worst, the FW team needs to
coax the CMS into thinking it's working for them, even if the
motivation is not primarily to make the CMS better (just a means to an
end). It's not that devious, the everyone can win.

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

Debate and decide - that's the point of the new Team structure isn't
it? This mentality has got to change. People that want to argue and do
nothing (but generate click-love to their personal blogs) just need to
butt out.

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

Yes but you have to start somewhere. Let me be brutally honest. Today,
right now, there is not point in the FW Team even being here other
than it's under the Joomla brand and moving to another brand means we
have to start again building our reputations and street cred. It's a
club at best, and a poorly attended one at that. If that's all it is,
it's a waste of resources and the PLT should decide to just nuke it
because it's a distraction to the greater whole.

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

Spot on - the user doesn't care. Just don't break anything.

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

The goal is to make it far less hit-and-miss than it is today. Those
1% of people, and I'm one of them, are experiencing 99% frustration.
If that can be lowered 10% a year it's a win.

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

That's what major version increments are for. The point here is to
either soften that blow, or delay it for as long as possible.

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

Sounds like a typical Joomla site with 10 totally disappoint
extensions installed. How many times to we out in the real world have
to say things are a complete mess for people to start listening? It
can't get any worse.

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

Ok this is going round in circles. I'm just going to have to wait
until you and George are available to chat in real time.

To be honest it's sounding like we can't do anything because it's all
too hard. And the fact that nobody else is chiming in leads me to
think that this is a dead end street to try and at least have a go at
fixing something - anything. If it's going to take 6 months just to
decide whether we have lunch today, it's not worth my time.

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.