Packages - Keep or Dump?

[Michael Babker]

So the Framework has packed on a good bit of weight and carries 43 packages today.  I think we need to look at putting the Framework on a diet.  Frankly, we have a fair bit of code that falls into the unused or unmaintained categories that can just be deprecated gracefully, or code that may be well intended but just doesn't fit into the scope of what we do.

Packages that should go:

- Facebook

- Google

- LinkedIn

- MediaWiki

- OpenStreetMap

- Twitter

Packages that are questionable:

- Archive

- Data

- Image

- LDAP

Thoughts?

[Johan Janssens]

Hi Michael,

Instead of slimming down, I think time has come to throw in the towel. The framework/platform was created with the idea that developers could create standalone Joomla applications. Lets be honest, this didn't happen. To date, we haven't seen any major uptake in the Joomla community, nor the wider PHP community. Developers looking for web application frameworks, are choosing for Laravel, Symfony, ... or others.

A little look at packagist shows that the Joomla Framework was only installed 5000+ times, compared to the more then 5 milion installs for Laravel, or more then 6 milion installs for Symfony.

- Joomla   : https://packagist.org/search/?q=joomla%2Fframework

- Symfony : https://packagist.org/search/?q=symfony

- Laravel   : https://packagist.org/search/?q=laravel

Contributions to the framework have also stalled completely. There hasn't been any serious commit activity since the latest 1.1.0 release in Feb 2014. See : https://github.com/joomla/joomla-framework/graphs/contributors

As for the separate packages released at https://github.com/joomla-framework, those are not getting installed a lot either, see https://packagist.org/search/?q=joomla Very likely because there are a lot better PHP libraries available today. 

Think it's more then fair to conclude that the framework/platform effort has failed. Nothing wrong with that. I know it's not easy to let go, but lets not waist time and energy on something that developers are not looking for. Instead lets bundle efforts and focus in moving Joomla forward as a content management system.

Johan

[Denis Dulici]

I can't say anything about using a whole but separate packages are a huge plus to the PHP community. We use some on our new Arastta project and could use more. However, I agree that, at the moment, the Joomla community is not able to handle and contribute both.

--
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-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

--

Regards,

Denis Dulici

[Michael Babker]

No, Joomla doesn't have the resources to compete with a corporate funded framework stack.  But the mentality that we just give up and go play in our little corner doesn't set well with me either.  No, the packages don't get a lot of traffic.  And no, using the combined Framework repo which was ripped apart in Feb 2014 isn't a fair metric either, a deliberate decision (that I don't necessarily agree with) was made to stop shipping a combined framework together and go to a modular release system.

That same argument about giving up IMO could be made about Joomla as a whole, just shut down development and use a CMS that's much better supported or structured.

--

[Andrew Eddie]

On Monday, 25 May 2015 02:09:35 UTC+10, Michael Babker wrote:

Packages that should go:

- Facebook

- Google

- LinkedIn

- MediaWiki

- OpenStreetMap

- Twitter

I think you should at least relicense them and push out 2.0 of those packages. After that, monitor for 12 months and see what happens.

 

Packages that are questionable:

- Archive

- Data

- Image

- LDAP

Same again.

Regards,

Andrew Eddie 

[Michael Babker]

If the API wrappers are going to get another release they should be caught up with their APIs.  A major problem with them is they've gone mostly unmaintained and are now behind their APIs in terms of feature support.  Given all of those packages have less than 100 downloads in the last 2 years, I don't see the effort to catch them up being a viable time investment.

As for the other packages, it isn't so much about disuse or disinterest.  The Data package never really caught on (as far as I'm aware at least), LDAP has always been an awkward thing (and we have no idea if the code actually works right now, there's zero tests around it), and the Archive package feels half-complete (it can only extract stuff, not usable for building archive packages).  Those last 4 packages have their uses, I'm just trying to think of ways to stop stretching ourselves thin and cut back on some stuff that was once a good idea but that time has passed.

--

[Andrew Eddie]

On Monday, 25 May 2015 05:30:43 UTC+10, Johan Janssens wrote:

Instead of slimming down, I think time has come to throw in the towel. The framework/platform was created with the idea that developers could create standalone Joomla applications.

The reasons were a little more complex than that.

 

Lets be honest, this didn't happen.

Actually it did, it just depends on your point of view as to whether the impact was worth it or not. Did the instigators of the Framework overcome the political argie-bargie that in part motivated the Framework to be born? Not entirely, and that is a problem that remains today be there a Framework Team or not.

 

To date, we haven't seen any major uptake in the Joomla community, nor the wider PHP community. Developers looking for web application frameworks, are choosing for Laravel, Symfony, ... or others.

One might ask why isn't all of Joomla following Drupal's lead and moving to Symphony. At least that would position the two projects to at least have a chance of interoperability.

 

A little look at packagist shows that the Joomla Framework was only installed 5000+ times, compared to the more then 5 milion installs for Laravel, or more then 6 milion installs for Symfony.

- Joomla   : https://packagist.org/search/?q=joomla%2Fframework

- Symfony : https://packagist.org/search/?q=symfony

- Laravel   : https://packagist.org/search/?q=laravel

I don't think the metrics for entire framework packages of any of those projects are remotely meaningful. You need to see the distribution of the individual packages. Granted, it will reveal that Joomla is still the underdog - but so what. It's not like other developers in our community don't choose to build and use their own frameworks rather than contribute to Joomla's core :P 

 

Contributions to the framework have also stalled completely. There hasn't been any serious commit activity since the latest 1.1.0 release in Feb 2014. See : https://github.com/joomla/joomla-framework/graphs/contributors

One could also argue there hasn't been any serious innovation added to the CMS in that time either ...

 

As for the separate packages released at https://github.com/joomla-framework, those are not getting installed a lot either, see https://packagist.org/search/?q=joomla Very likely because there are a lot better PHP libraries available today. 

This is a good point. And if it's true, another option we have to steering the CMS to use those better PHP libraries.

 

Think it's more then fair to conclude that the framework/platform effort has failed. Nothing wrong with that. I know it's not easy to let go, but lets not waist time and energy on something that developers are not looking for. Instead lets bundle efforts and focus in moving Joomla forward as a content management system.

That doesn't really solve the underlying problem, it just shifts it to a different mailing list. The CMS code is still old and irrelevant and by and large untested by today's standards. It doesn't obviate the need to think modular. Regardless whether the Framework Team in it's current form lives or dies, since (I hope) Joomla's leadership is leaning towards a more "product focused" project (as indicated by the corporate flavour in the recently adopted organisational structure), it makes sense that there will be a team laser focused on library code that higher functions of the CMS might use. 

It doesn't mean that you suddenly stop using Composer to maintain our own packages. There are very good reasons for doing so even if only the Joomla CMS is using any single package. And if that's the case, I would expect to see a Team handling that grunt work one way or the other.

So while it's easy to be very dismissive of where the Framework Team has ended up (and the reasons for that are both complex and nuanced), it doesn't mean that the Joomla CMS product doesn't need some leadership in significant code reform, and that should most certainly happen in a modular way.

Regards,

Andrew Eddie

[Andrew Eddie]

On Monday, 25 May 2015 08:04:09 UTC+10, Michael Babker wrote:

If the API wrappers are going to get another release they should be caught up with their APIs.  A major problem with them is they've gone mostly unmaintained and are now behind their APIs in terms of feature support.  Given all of those packages have less than 100 downloads in the last 2 years, I don't see the effort to catch them up being a viable time investment.

Ok. I'd still vote to relicense them even if that's under the 1.x version. We owe it to the people that fought hard to make that happen.

 

As for the other packages, it isn't so much about disuse or disinterest.  The Data package never really caught on (as far as I'm aware at least),

No, I'd also suggest a different direction now anyway, if not use something off the shelf.

 

LDAP has always been an awkward thing (and we have no idea if the code actually works right now, there's zero tests around it), and the Archive package feels half-complete (it can only extract stuff, not usable for building archive packages).  Those last 4 packages have their uses, I'm just trying to think of ways to stop stretching ourselves thin and cut back on some stuff that was once a good idea but that time has passed.

That's fair. But as I said, I think the relicensing should still happen even if only to put some those packages to bed once and for all.

Regards,

Andrew Eddie

[Andrew Eddie]

> Probably are, does that matter ?

If a comment doesn't convey the right context, yes.

> Looking at it from a ROI perspective. The investment that the Joomla
> community made in building, promoting and maintaining the framework didn't
> generate any significant uptake by Joomla nor PHP developers.

Compared to the investment put into the CMS and other non-code related
activities, the investment was tiny. It doesn't really matter though,
it scratched an itch then but what's important is what does Joomla
need to do now?

> I would go even as far as saying that the framework effort and the "politcal
> argie-bargie" has had a quite negative impact on the Joomla brand perception
> and diluted the brand significantly.

No less than Nooku or FOF or several others that have come up. To be
clear, there are good reasons why those exists, (and I include
JXtended libraries which I was involved in), but they all, in some
capacity dilute the brand and have a slight negative impact on core
contributions. Despite understanding, and partly agreeing with, the
reasons, FOF vs F-zero-F was far from an ideal situation to find
ourselves in (as consumers of Joomla), and Nooku openly competed with
Joomla on a commercial level for a while there.

So while your statement is true, the Framework finds itself in good
company and like all the other examples, it's not just the Framework's
fault. Other forces also contributed. However, none of that really
matters now. It happened. Change is required. So change.

> There are definitely some very good and well established libraries out there
> worth using. Symfony has some great components, the League of PHP is doing
> some excellent work too.

I agree. The only thing I don't like about Symfony is some of the
baggage you have to include to use just one or two packages. Same
would go for Laravel but it is certainly my favourite. They are
designed to be used as an entire framework. I prefer the way the
League and perhaps Aura is doing things. To be honest I'd be more than
happy if the CMS said they just wanted to use someone else's
framework. But that doesn't mean the need for the responsibility of
library maintenance disappears. I think it's better done in a separate
team. I don't think one CMS Team can be the expert at everything (and
it's certainly not my experience working for other people on software
that isn't even as big as Joomla).

The question I ask Joomla is does it retain in-house expertise to
guide and maintain the types of libraries that are included in the
CMS, and who sets the standard for what code is written in-house?
That's where I think a new type of Framework Team is necessary, and I
assume that Team would still decide to store packages in separate
repositories and bring them all together with Composer (or some other
distribution system).

The CMS proper, and even extensions, should actually be made up of
very few lines of code. Most of the heavy lifting should be hidden
away in the /vendor/ folder.

> Metrics are more then clear, 5000 vs 5 million even with a different
> distribution line it doesn't matter. Lets not blame this on the 'other
> developers'. Doesn't matter who contributed and who has not. There is no
> uptake of this code, time to put it to bed.

It's still a nonsense argument in my opinion. Composer can still be
used as a distribution model even if only the CMS is using it. The CMS
still needs good, clean, modular code. Yes, we all agree the original
purpose of the Framework Team doesn't exist any more. That can be put
to bed. Is a new purpose required - of course it is.

> That's NIH thinking.

How so?

> Innovation doesn't come from what you add, it comes
> from what you make possible. CMS is still pushing Joomla developers to
> create great an innovative extensions.

I don't share your point of view. The certification side of things is
still in its infancy. I don't see a clear and deliberate campaign for
innovation within the project itself, let alone exuding it, but then
maybe I'm looking in the wrong place. I do, however, come across of
lot of really, really bad code in extensions and what I'd class as
genuine innovation is rare (and that's normal). But who can blame them
when the code in the CMS is partly to blame for setting a bad example.

> The stability and lower pace of
> change of 3.x series is actually driving factor. The framework hasn't seen
> any uptake at all. Clear cut case.

Not clear cut because there has been "some" (where some means greater
than zero) uptake (if "you" don't use it doesn't mean zero other
people use it). It is a clear cut case that the framework in it's
current form has failed to reach any reasonable level of popularity as
originally desired.

> Dropping any of the framework packages used in the CMS that have better PHP
> community equivalents is definitely a good idea. Allows Joomla to focus on
> it's core task, making the Joomla the best possible content management
> system.

Can't agree more.

> That's NIH thinking.

For those watching with popcorn, NIH stands for Not In Here, or Not In House.

It's got nothing to do with it at all. I don't care what code is
in-house and what isn't. It still needs to be managed.

> Joomla doesn't need a separate framework, it can easily
> adopt established PHP libraries to serve lower level functions, it doesn't
> need to build it's own complete framework for that. Result : a laser cut
> product focus on 'Joomla' as a cms.

I agree that it doesn't need a complete framework for that. But it
will need "a" framework most probably a mix of off-the-shelf and
bespoke code. The ideal would be for a distinct team to take care of
that. Gosh anyone who works with any Node application of any size
knows it's almost a full time job for one person just to keep up with
dependancy updates.

> I'm not saying you need to stop using Composer. Just use it in the correct
> way.

What is the correct way in the context of your statement?

> Think the Joomla community has some very talented extension developers out
> there that are most happy to help with this.

They are free to join in the conversation. I see Nic D wants to. Very
encouraging.

Regards,
Andrew Eddie

[Robert]

Am Sonntag, 24. Mai 2015 18:09:35 UTC+2 schrieb Michael Babker:

So the Framework has packed on a good bit of weight and carries 43 packages today.  I think we need to look at putting the Framework on a diet.  Frankly, we have a fair bit of code that falls into the unused or unmaintained categories that can just be deprecated gracefully, or code that may be well intended but just doesn't fit into the scope of what we do.

Packages that should go:

- Facebook

I tried this one in a project and could get it running so drop it. 

Cheers,

Robert

 

[piotr_cz]

I think this is not a proper question for this time.

The truth is that there are better packages out there and that's why developers choose them, Joomla brand is not enough.

We should start architecting new CMS generation and then see which packages out there are best for this task. If some of the Joomla Frameworks fit most, let's keep them.

And depreciate the rest.

For example: Database package is not bad, but I'd rather use Laravel's Eloquent or Doctrine DBAL, as it's much more mature and has multiple drivers support built in. Seriously - we can't compete with these.

[Andrew Eddie]

> For example: Database package is not bad, but I'd rather use Laravel's
> Eloquent or Doctrine DBAL, as it's much more mature and has multiple drivers
> support built in. Seriously - we can't compete with these.

Actually we could because most of the ORM's only support RDBMS's in
the backend. However, when you go to Node, there are several that are
truly DB agnostic, even allowing memory storages will association
support. And none of the PHP ORM's are anywhere near as nice as the
Node counterparts (in my opinion).

So there is an opportunity to compete but on a different level (and
without "magic").

Regards,
Andrew Eddie

[dgt41]

The idea of using the micro framework of laravel https://github.com/laravel/lumen

and keep the other good packages from the Joomla Framework should be a twist...

[Andrew Eddie]

Middleware! (/me jumps up and down erratically)

Ok, I'm sold. When can we start refactoring :)

Regards,
Andrew Eddie

[piotr_cz]

Yeah, I'm into Laravel too, but I can't see much difference between the Laravel App and Lumen App.

For example Lumen framework requires Illuminate/Database, Illuminate/Cookie and other 20 Illuminate packages.

Last time I checked it was not possible to use Illuminate/Foundation (Application bootstrapper) without pulling in another 15 packages so I decided to use Slim instead for a simple project.

What I'm saying: If we decide to use Laravel/ Lumen/ Illuminate probably we have to load (and use) most of it's packages.

This may be a good move for Joomla, but everybody should be aware of this from the start.

[dgt41]

They advertise that it is faster than slim and silex, if that is a metric that needs to be considered

[piotr_cz]

yes, seems to be pretty fast.

Some reading:

How Lumen Is Benchmarked
Why my Lumen is so much slower than Taylor's?

[dgt41]

Even if the numbers are lower than those advertised the main point here is that Lumen is faster than Silex and Symphony. Why?

Because Drupal embraced Symphony and they shouting around victory!

And if Joomla ends up with Lumen will have a great opportunity for all the obvious reasons:

- Lumen is faster than Symphony or Silex

- It’s also faster/easier to create apps (we should make sure the same will be true for components/plugins)

- Joomla offloads some critical code maintenance/update and thus will be more focused on the part that will maintain

- there is a big community (those outside of the joomla) that will quickly get involved 

- Most of us (inside of the joomla community) will be happy to see Joomla not trying to do everything in house

So follow the trend, embrace a (micro or not) framework and build on it!

Sorry Mike for ruin this thread, I stop here.

[Michael Babker]

I just wanted to try and get a focus on dropping some of our "bloat" code, didn't realize this was going to turn into a "rewrite Joomla" thread in doing so LOL

--

[George Wilson]

Packages that should go:

- Facebook

- Google

- LinkedIn

- MediaWiki

- OpenStreetMap

- Twitter

These are the packages that actually 'worked' when the framework came into being (with the exception of mediawiki for obvious reasons). I think as 2.5 support starts dropping off these are the kinds of packages that we should be promoting heavily in the CMS - so many people get extensions that do this for them when we can manage it 3rd party. Especially when we refactor HTTP (whether PSR-7 compliant or not) so that dropping in Guzzle becomes viable to these packages, I think these could go futher.

Kind Regards,

George

[Nils Rückmann]

It's obvious that there are very different opinions about the Framework and the CMS. I mean, there are even opinions to drop the Framework at all. And i don't see that all those people will find a common ground in the near future. So what's about this:

A new "Icarus" playground project ( with a better name ;) ) which is under the Joomla brand, but independent in a way that it has his own leadership. No investments are necessary. Just give those people who wants to work on a modern base a playground where they can share thoughts and build modern libraries together. If it's going down like the current Framework, there will be no bad blood, because of endless fights between different teams. And if it succeed, well, then we all should proud and of course use the new code in other Joomla projects.

[Andreas Tasch]

Hi,

I think it makes totally sense to really keep only a handful Joomla! Framework packages and pick all other stuff from matured composer packages - thats the whole idea behind composer, npm and those other package managers. The framework devs should compose a set of packages to built on (with all ther knowledge and insight) - after that there will still be enough work left to build a next-gen core.

Take Drupal, I think what they do makes totally sense. Choose a framework or single packages which do the basic stuff and extend from there. They use some Symfony packages but stick with their own kernel implementation [1] and add other nice packages as Guzzle. Take a look at their composer.json: https://github.com/drupal/drupal/blob/8.0.x/core/composer.json, they even use a zend framework package. Why not. Better to contribute back to already mature packages and do not reinvent the wheel. Use all that now free manpower to focus on the main product.

[1] https://cipix.nl/understanding-drupal-8-part-1-general-structure-framework

[piotr_cz]

Yes. What I'm saying is that it will be better time to ask ourselves which packages to drop when we will know which we will need and which not.

At this point I think we should keep at lease in maintenance mode all that are already bundled with CMS.

For the next CMS version, when we will have a better picture we will need to reevaluate, just like Andreas said.

But no major refactorings at this point.

For example I haven't found a good and simple i18n package out there that beats JLanguage so maybe JF Language v2 is may be best on the market.

[Andrew Eddie]

> For the next CMS version, when we will have a better picture we will need to
> reevaluate, just like Andreas said.

One of the really frustrating things is nobody can tell me what the
next version is supposed to be. Is it supposed to be highly compatible
with 3.x? Can we break heaps of things but include a legacy layer?
Without knowing exactly what we are aiming for, it's really hard to
know what to keep and what to drop with any certainty. What's worse is
nobody can tell me how anyone is supposed to decide.

Regards,
Andrew Eddie

[piotr_cz]

I guess it's time to pull all remaining interested parties together and start a discussion with at least little official support.

maybe open letter to OSM or somebody who is in charge.

[Andreas Tasch]

> One of the really frustrating things is nobody can tell me what the
> next version is supposed to be. Is it supposed to be highly compatible
> with 3.x? Can we break heaps of things but include a legacy layer?
> Without knowing exactly what we are aiming for, it's really hard to
> know what to keep and what to drop with any certainty. What's worse is
> nobody can tell me how anyone is supposed to decide.

As long as there is a very solid core migration available it won't end in a desaster like from 1.5 to 2.5. So, before there is no agreement on a first class stable migration path we shouldn't discuss further. If a migration path + step by step guides for extension devs are considered as part of the next release the option with the legacy layer is maybe the safest one for the community and sceptics. I would prefer the easier an cleaner way but I think after 1.5 to 2.5 there is no majorty for a ground approach without a legacy layer. 

--
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 a topic in the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-framework/EmmkXmwhbUk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-frame...@googlegroups.com.

[Johan Janssens]

Hi Michael,

I can understand that my reply was not the reaction you are looking for. Sorry about that. It was the first response that came to mind.. 

I'm not suggesting Joomla should go play in it's own little corner, just trying to putting focus where focus should be. Looking at it purely based on install base the CMS is used by 3% of the internet, the framework has max 10k installs...

Lets considered another way of looking at this. Instead of discussing what packages to remove, what about looking at what packages are worth developing further for a 2.0 release ?

In your request you state :

 "Frankly, we have a fair bit of code that falls into the unused or unmaintained categories that can just be deprecated gracefully, or code that may be well intended but just doesn't fit into the scope of what we do."

Could you explain a bit what the scope you talk about ? This will help me to get a better idea in what context to understand your question.

Thanks!

Johan

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.

[Michael Babker]

Quick message as I'm in the airport security line.

Instead of carrying out full stack through another major version cycle, I'd rather focus on a subset of things that are going to be more useful to the Joomla community, while continuing a modular approach giving potential to use that code outside the CMS context.  For me that means focus on stuff that helps application infrastructure first and support systems second.  Our social APIs for me fall outside that scope (minus GitHub, it's built into the heart of a few tools in our community).  At the FW level, I'd make sure our app, database, language, and session packages are in tip-top shape.  This pulls forward things like input sanitization (input and filter packages).  Step 2 for me would be in areas like the string package (UTF-8 support), our HTTP client, date/time handling, and things that are really baked into the core of our app structures.

Everything else, evaluate for better options and decide if it's worth keeping the code.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@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-frame...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-framework.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Andrew Eddie]

> I'm not suggesting Joomla should go play in it's own little corner, just
> trying to putting focus where focus should be. Looking at it purely based on
> install base the CMS is used by 3% of the internet, the framework has max
> 10k installs...

Yes but the Framework is still included in the CMS so the distinction
is somewhat moot.

I don't think anyone disagrees that the Framework as a marketing
exercise has been a complete failure. So should we give up on
perpetuating that idea? - sure, why not.

> Lets considered another way of looking at this. Instead of discussing what
> packages to remove, what about looking at what packages are worth developing
> further for a 2.0 release ?

For the sake of it or for the benefit of the CMS? If the latter, that
would necessitate the CMS actually having a technical roadmap to be
able to determine such things. If the former, as I've said, there are
better niche projects to align with to do that than the Joomla brand.

Regards,
Andrew Eddie

[Andrew Eddie]

> As long as there is a very solid core migration available it won't end in a
> desaster like from 1.5 to 2.5. So, before there is no agreement on a first
> class stable migration path we shouldn't discuss further. If a migration
> path + step by step guides for extension devs are considered as part of the
> next release the option with the legacy layer is maybe the safest one for
> the community and sceptics. I would prefer the easier an cleaner way but I
> think after 1.5 to 2.5 there is no majorty for a ground approach without a
> legacy layer.

I agree, this needs to be in place. The question is how to do it.

Lead code reform in the CMS by "grafting" in new code into the 3.x
series so that developers can opt-in, and then we drop all the old
code in Joomla 4?

Or, design improvements for Joomla 4 the right way, probably with
significant changes, and adding a legacy layer for 3.x extensions to
run?

I think the first option is a better experience, but it's a lot more
work in the short term.

The latter is better for developers that really want to make
best-practice changes, but you have to stay on top of the legacy layer
and not leave it to the last minute (and it goes without saying the a
massive automated testing effort needs to be part of any such goal).

Who decides? Can the Framework Team Members just make that decision?

Regards,
Andrew Eddie

[Andreas Tasch]

> I agree, this needs to be in place. The question is how to do it.
>
> Lead code reform in the CMS by "grafting" in new code into the 3.x
> series so that developers can opt-in, and then we drop all the old
> code in Joomla 4?
>
> Or, design improvements for Joomla 4 the right way, probably with
> significant changes, and adding a legacy layer for 3.x extensions to
> run?
>
> I think the first option is a better experience, but it's a lot more
> work in the short term.

I think the first option is not the right way to go. Not worth as  the j4 API has to be finished before backporting such a forward layer. This ends still in a scary gap for ext dev as there is no legacy layer in j4 then?

>
> The latter is better for developers that really want to make
> best-practice changes, but you have to stay on top of the legacy layer
> and not leave it to the last minute (and it goes without saying the a
> massive automated testing effort needs to be part of any such goal).

Imo thats the safer way. As you could deprecate later in 4.x od w 5?

>
> Who decides? Can the Framework Team Members just make that decision?

Maybe
Call me naive but maybe the dev separation is a problem. FW + CMS + EXT = joomla devs should agree together if this approach is the right way forward and then pull other stakeholders in.

[Andrew Eddie]

> I think the first option is not the right way to go. Not worth as the j4
> API has to be finished before backporting such a forward layer. This ends
> still in a scary gap for ext dev as there is no legacy layer in j4 then?

Correct, but it means that 4.x does not need to be released for a very
long time (you are grafting 4 into 3 to allow developers time to
change). So the first option is equivalent to, for example, doing
4+legacy and then releasing 5 without the legacy layer.

But the more I think about it, a clean break and a legacy layer is
going to be the easier option to work with. The code in the CMS is so
old it's just not worth trying to fight with it.

> Call me naive but maybe the dev separation is a problem. FW + CMS + EXT =
> joomla devs should agree together if this approach is the right way forward
> and then pull other stakeholders in.

Interesting you should say that. So George and I were just talking
about things in general today, and the suggestion came up to move the
Framework Team under the Joomla 4 Team (when that exists properly). I
think I do like that idea.

Just thinking out loud, if the Joomla 4 Team was made up of a
framework team, an application team (the actual CMS part with
extensions), a UI/UX team, a documentation team and a quality &
testing team, I think we'd be in a really good place to move forward.

It would be interesting to hear if other people thought about that
kind of concept.

Regards,
Andrew Eddie

[Troy]

On 5/26/2015 21:34, Andrew Eddie wrote:
> Just thinking out loud, if the Joomla 4 Team was made up of a
> framework team, an application team (the actual CMS part with
> extensions), a UI/UX team, a documentation team and a quality &
> testing team, I think we'd be in a really good place to move forward.
> It would be interesting to hear if other people thought about that
> kind of concept. Regards, Andrew Eddie

I know i'm not the best coder but I'd like to throw my observations out
there..
first, I like this idea the best. Makes perfect sense. The application
team can decide what it needs, tell the framework and ui folks that info
so they can work their respective magic, the doc team can then create
SOLID USABLE information ( not just here's a class and its children )
and the q/a can build the tests. Makes perfect sense and is the way big
business does things afaik.

I'd like to throw out one caution though. I hear some core dev's
complain the code in the cms is horribly outdated. well, I'm not sure
how that can be but ok. What I do see is the constant changes of
names. For example we have JDocument and JHtml. Some say using one is
better then the other but yet they both do pretty much the same thing.
Soon we'll have JLayout which will change things yet again. Let's
please think ahead and pick one class family name and stick with it.
deprecate everything else!!
If things need to be non b/c in 4.0 so that the cms and other apps can
mature then do so! Don't "tweak" other libraries to fit joomla, if
thats needed then make our own or tweak joomla to fit theirs so that we
can keep the underlying libraries up to date and as bug free as
possible. Bootstrap is a great example of what should be fairly easy to
update and yet has stagnated to the point where we need to seriously
look @ skipping BS 3.x and jumping to 4 which is due out in the near future.
From what i've seen and read there were few enough changes between 2
and 3 that we could've done the rewrite already if it had been more
centralized.

Lastly we've got an ancient menu system. a dropdown type Horizontal
menu and solid ( offcanvas?) mobile menu should have made its way into
core years ago. Lets fix this in 4.
Bear

[Walt Sorensen]

Some of my observations

Some packages of the Framework are considering significant shifts that would include adopting 3rd party packages.
For example there is a discussion/suggestion for the database package to adopt Doctrine DABL for v2 https://github.com/joomla-framework/database/issues/18

I think all of the Packages within the framework should consider something similar. The ones listed for removal consideration by Michael are of the highest for consideration; is there something that could be adopted to improve the existing packages and reduce our maintenance requirements.

Framework + CMS is an ongoing discussion, there is definitely some angst with the whole direction of the framework/CMS currently and rightful concern about development resources.
I agree that developers looking for web application frameworks to build a product are rarely, if ever, going to look at the Joomla Framework. That being said keeping those as separate packages and adopting them in the CMS does have some advantages (light weight version of the CMS maybe); but the current implementation of the framework in the CMS is confusing at best and a disaster at worst. Especially in areas where the CMS results in it's own code plus the framework rather than just an extension of the Framework (forms anyone). 

I agree that updating an releasing a V2 for the framework packages is more than needed, and should be expected. Some of that should be refactoring, and innovation, but a lot can be said about just updating things that are relying on outdated API versions.

Moving towards a Framework v3 and CMS v4 whatever direction is decided a legacy layer should be expected, with clear guides in the documentation for developers on how to convert/migrate. One of the ugly legacies of Joomla has been the 1.x to 1.5 migration, the 1.5 to 2.5 migration, and to a lesser extent the 2.5 to 3.x shift. Users have often complained about the difficulties which often revolve around data issues and extensions that suddenly don't function due to a lack of a legacy layer to provide some B/C in the moves. Don't get me wrong each of these moves was more than necessary, some did not go far enough. Developers also complain due to the lack of a legacy layer to provide some B/C resulting in significant refactoring and clients complaining about version incompatibilities. One of the things that has helped wordpress keep and grow market share is their effort to maintain B/C through 1-2 versions and effort to insure that the user experience for moving from one major version to the next is seamless and simple even when it is complex behind the scenes. This effort helps keep users and developers happy and engaged in the product.