Version 2.x needs a tag about di HOT 12 CLOSED

PSR-11 support was backported onto 1.x and a 1.5.0 tag created.

from di.

33c66e4 should address that (as well as resolve #4 for 1.x).

from di.

The 2.0 branch implements the interface, 1.x does not.

from di.

Oh, I see, but the 2.0 branch isn't tagged yet, right?

from di.

Right.

from di.

Would it be possible to get a tag so we can start using it now? I note development seems to have slowed down since it hasn't been touched since August. I don't know if that means it's stable enough for a tag yet.

from di.

Internally I think we still need to come up with a master release plan for the Framework 2.0 packages. In general I think the aim has been to tag those with the CMS 4.0 release next year.

In general though, aside from the Form package, each of the other 2.0 dev branches should be stable enough for use and I don't foresee many other major changes that would cause issues if implementing them now.

from di.

I don't foresee many other major changes that would cause issues if implementing them now.

Being as that's the case, why not just add a stable tag now? I don't use Joomla so I don't know how your releases work typically, but I am interested in a quality, lightweight DI container that's less bloated than what Symfony, Zend, PHP-DI, etc. are offering and this package seems to fit the bill nicely.

from di.

I'll talk this over with a couple of others and work out a plan. Conceivably we should be safe to start tagging at a minimum betas if not stable for the 2.0 branches, personally I think it's now more of a question of when versus whether there is more effort needed.

from di.

OK I'll leave this issue open but rename it to reflect we're waiting for a tag 👌

from di.

@mbabker Unfortunately I cannot use v1.5 because it is not logically compatible with 2.x. I normally use buildObject() to retrieve my services because they might be aliases or instances. However, v1.5 is missing the resolveAlias() call in that method, so it can never build objects that are aliases. I also cannot use the get() method because, although it will resolve aliases, it complains the object hasn't been registered with the container yet (i.e. it needs to be built). This is a deadlock and I cannot proceed with v1.5 at this time.

from di.

Some of these internals I think we can fix on the 1.x branch. buildObject() should definitely resolve aliases as it's a pretty common practice to alias a concrete class to an interface as we do for our default database service provider in that package, and we don't require aliases be mapped to registered services only.

from di.