[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [jfw] Versioning namespaces
Let me be more clear about the problem I am trying to identify:
1. No developer or user likes B/C breaks
2. Historically the project, imo, has not recovered from the severe
break from 1.5 to 1.6, and then the template break from 2.5 to 3.
3. Trying to negotiate or agree on the amount of B/C we can break
going from 3 to 4 is hard (Joomla community sucks at negotiating,
they'd rather burn the farm than compromise).
4. Therefore a fight on two fronts (we need change, and we need to
convince others they need to adopt the change) is harder than one (we
need change, and you can opt into it when you need to).
5. Fighting on two fronts, historically, leads to your best dev's
loosing interest because they spend all their time trying to justify
the work they want to do rather than actually doing it (death by
6. It's better to get behind some idea that could lead to a modicum of
success than to do nothing and continue to loose momentum.
The disadvantages of this approach are that it leads to code bloat,
and it can lead to confusion about which "code" to use, and it does
make it hard for site builders to customise when you have different
developers using different standards (although my experience is that
the bar is not that high so anything is better than nothing).
The alternative, however, is the continued paralysis that this project
is experiencing in terms of forward innovation and architectural
Something's got to give.
On 19 May 2015 at 09:19, Andrew Eddie <mamboblue AT gmail.com> wrote:
> Because I can't help myself, I've been thinking a lot about how I would
> construct Joomla 4 given the chance (3 words - test-driven-development). One
> of the big drama's is always backward compatibility.
> Historically speaking, our greatest site migration success has come with
> keeping new work parallel (ala 1.0 to 1.5 legacy layer style) as opposed to
> a clean break (1.5 to 1.6 style).
> That got me thinking. What if you used the package namespace to support
> different major versions of a package so that the old and the new code could
> installed side-by-side. Would that allow the CMS to be able to stay within a
> minor version longer? Perhaps.
> Here's an example.
> Let's say we convert Joomla 3.x to use the Composer installed Model package
> and some refactoring of core is done to keep things up to date.
> Let's assume it's v2 of Model that's been released as LGPL (/me folds arms
> and taps foot).
> Let's say some of the better extension developers follow suit.
> Now we want to do a major upgrade to the Model package. Right now, we are
> stuck adding that to core until 4.x. But what if v3 of the model package was
> namespaced as "Model3" where "3" is the major version of the package. Now in
> Composer we can install Model and Model3 in the same install, and old and
> new core and old and new extension will work side by side. It could be that
> Model3 still used most of Model, but just changes interfaces or whatever.
> In the code, older elements would use:
> `use Joomla\Model\Model as Model`;
> and newer elements can say:
> `use Joomla\Model3\Model as Model`;
> Alternatively you could do something more traditional like (makes Composer
> SemVer a little more interesting):
> `use Joomla\Model\v3\Model as Model`;
> Type hinting is still a bit curly, but as long as there is a rule that only
> interfaces are allowed for type hinting, I think we can get around it.
> There is already a sort of precedent with FOF and F(zero)F where this kind
> of thing has had to happen (I'm not complaining about that happening, I just
> think it can happen in a different and better way). Outside of Joomla, best
> practice for RESTful API's for example is to version them from the outset,
> usually with a `v#` prefix in the route - so this is not a new idea.
> Much as I hate trying to accommodate old code from staying on life support,
> trying to fight that mindset is too hard so it's easier to just work around
> The advantage of this type of strategy is that it will provide the CMS
> community some confidence that they can put off the worry of doing a full
> blown migration anytime soon. I believe it also means that the Framework
> Team can take the lead on a single attack front of architectural reform
> without also having to fight for how much change they are allowed (don't
> care - y'all just keep using the old code if you want). At the end of the
> day, as long as the site still works after an upgrade is all the User cares
> about, and the Developer is only worried about whether you break their
> If the Framework Team can essentially work on the new engine for Joomla 4
> within Joomla 3, I think that gives this team great purpose and identity.
> The CMS team can then concentrate on building out user-facing features. To
> be honest, the strategy could last indefinitely (though there are practical
> limits on how much code bloat you want to keep in the core).
> Thoughts or alternatives?
> Andrew Eddie
> Framework source code: https://github.com/joomla-framework
> Visit http://developer.joomla.org for more information about developing with
> 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
> To unsubscribe from this group and all its topics, 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.