HI Andrew, am i right that you suggest different packages/repositories for each major release ? I'm not against it, it's the same approach which is used by many libraries in the deb-universe. I just want to ask if i understand your proposal. It's a pity that composer can't handle multiple versions of the same package.
--
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.
I admit, it's not ideal. But it has benefits with minimum effort. Personally i don't know any other solution to solve the issue with multiple version. Well, there would be the possibility to bind a package and its dependencies like Snappy (and others) does, but that's no solution for php.
--
--
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.
Please pardon any errors, this message was sent from my iPhone.
> Is there an interface for each major version or just one interface?
I think the question is the wrong way around. You only bump the major
version when you make a backward compatible change to any interface.
I'm also assuming you aren't locking every package in the FW to
exactly the same version number (if you are, yeah, this plan sucks and
is completely unworkable).
> If the CMS is using the v2 API,
> how can an extension use the v1 API then?
I'm getting a bit lost. Are you talking current v1 and v2 of the FW,
or speculating on a future version? My assumption is we are working
with V2 of the FW but only because that is what has to happen to
relicense it.
> I'm not trying to build a higher brick wall each time it's climbed, but
> these are issues I see with an application environment supporting two major
> versions of two separate APIs (right now, we very realistically are talking
> about 3 separate versions of APIs in some cases).
Ok, so let's take a few steps back. Of what's in
https://github.com/joomla/joomla-cms/blob/staging/composer.json,
what's planned to have a breaking change in V2 of any of our packages?
Regards,
Andrew Eddie
So in one respect, the FW has been doomed from the very beginning, not
because the idea is wrong, but because the community allows and
tolerates too much rubbish to be thrown at its best contributors. To
fix that, however, requires strong and gutsy leadership and, nothing
personal, but we have simply not seen that in Joomla leadership for
many years. The reason, I think - and I understand and empathise, is
out of fear of causing yet another drama.
OR, the PLT needs to restructure the teams so that people that want to
talk about code and talk about code without users interjecting because
they simply don't understand what's being discussed.
But no matter how you slice is, code reform is needed and the scope is
simply massive (so you are going to need all the experience you can
get). How on earth do people help make that happen?
I'd love to start from scratch, but my concern is the community would
not forgive us "again" (after 1.6). I think the only practical way to
upgrade the CMS, and justify this team, is to do it by stealth.
If you mentor new devs supplying them with the best practices to ensure their code is correct (writing tests, code style etc). The iterative process will produce a positive feedback loop where by devs see the fruits of their labour in a short time, are encourage and enthused by the results and then want to repeat the process, the complete opposite of the current negative feedback loop when you bust a gut for a month on something you personally deem important only to have someone block it based on some arbitrary requirement you weren't even aware existed before you started.This is also why I'm against say "lets start again from scratch". It reduces confidence in the merit of incrementally contributing to the existing code, and leaves those dev's not capable or willing to work out an entire new architecture watching from the sidelines.
95% of those developers will be coming from the CMS, and that is where their interest lies. When I do a custom project realistically I am not going to use the Joomla framework, I'd sooner work on Express or Laraval, or pick individual composer projects few of which would be those available in the framework. So for me the Joomla Framework is only relevant IF its directly feeding into the CMS. I'd love to see that change and for the framework to become my defacto choice, but it will only ever get there if there are a lot more people contributing to it, and to get those contributors we need to set up a short positive feedback loop in the contribution process.
With regards to Andrew's idea of version'd classes. To my mind there are definitely certain classes which you would not want multiple versions of. JSession, JApplication etc. Basically any class which is required to be initiated before the call stack arrives at a component/plugin entry point should be a known quantity for a 3rd party developer. However MVC etc could have different versions, indeed we already have that in the fact that JModel and JModelLegacy are already in the CMS. I'm currently refactoring Fabrik to use namespaces and the new MCV classes. What I hadn't really appreciated before starting was that it really does allow you to easily swap out class definitions. So you can start with :