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

Re: [jfw] Versioning namespaces

On 20 May 2015 at 12:02, Michael Babker <> wrote:
> Once you get into components and modules, it's possible then you could have
> an app that supports two major version branches; there is some flexibility
> there.  How do you deal with application APIs that are infrastructure in the
> app itself, i.e. JDocument, session, installer, or app classes themselves,
> without introducing circular dependencies across major versions?

That's all part of the exercise. I don't have the answers until we
start looking at the code in detail. Even then, it will be taking
small, steady steps at a time.

It's a "we won't know until we get there" type of problem, but it's
better than nothing.

> If we
> refactor the session API, where does the SessionInterface get defined, in v1
> or v2?

If that's a FW version, then I'm assuming this is all V2 LGPL code
(but it could be V1 if you are ok with changing to the LGPL now which
I think would be perfectly fine, but it's not my call).

> 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 you go through with the idea some seem to have of making interfaces a
> separate package, how do you version those?

I've already said previously, don't make this a problem until it's a
problem. Keep the interfaces in packages until there is demand for
them to be separate.

> 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
what's planned to have a breaking change in V2 of any of our packages?

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.