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

[jfw] Versioning namespaces



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

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

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?

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.