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

Re: [jfw] Versioning namespaces



So I'm basically using the two major versions of both software platforms right now; v1 and v2 of the Framework packages, and v3 and v4 of the CMS.  Just to try and make that clear.

On Tue, May 19, 2015 at 11:32 PM, Andrew Eddie <mamboblue AT gmail.com> wrote:
> 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).

Right, but does the namespace of the interface then change too?  So you could have \Joomla\Session\SessionInterface in the 1.x branch then \Joomla\Session\v2\SessionInterface in the 2.x branch.  How are the two branches remotely compatible with one another then?  Your idea suggests that developers may be able to use both versions of the API in parallel, but if CMS v4 is built using the Session v2 code, how can an extension use the Session v1 API then?

In truth, I think I can live with the hole we've dug ourselves into with 30+ individual components going on 30 different paths as far as versioning goes, but only within a major branch.  I don't think it'd do us a lot of good to have Database v3, Application v2, and Registry v4 all floating around as the "active" versions, that'll get confusing quickly (and yes I know that's really hypothetical but I hope it illustrates one of the things I dislike about a scenario that idea allows to happen).

> 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 speculating on the v4 CMS codebase.  You're suggesting that the API be versioned via namespaces (which the only way to do this with Packagist is creating new packages for every major release because that and Composer won't let you install two versions of the same code), so in theory you open the door for a CMS extension running on a potential v4 of the CMS which is running the CMS v3 "legacy layer" and potentially uses Framework v1 code.  Reading this, it's really confusing, but it makes sense in my head, I swear!

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

Of what's there today, the only package with a roadmap idea that may have B/C implications is splitting off the Registry package's loader classes to form some sort of abstract layer usable for different purposes (one idea floating around is adding support for more file formats in the Language package, which would serve the PHP community moreso than Joomla most likely).  That also implies that no other Framework packages will get merged into the CMS for the remaining lifetime of its 3.x branch.  If the Language package gets integrated back into the CMS, that one would have B/C implications going between major versions.  And on the MVC side of things, the current v2 View package is a fair bit different than the previous version.

And truthfully, if even half of that roadmap post sees any action, there's a good chance other stuff will break.

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