Version 2.x needs a tag

[Bilge]

For whatever reason, joomla/di appears in the list of packages providing psr/container-implementation, and yet it does not: this package is not PSR-11 compatible in any way. I honestly have no idea how a package ends up on that list, but if it is under your control, I think it should be removed from that list.

[mbabker]

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

[Bilge]

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

[mbabker]

Right.

[Bilge]

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.

[mbabker]

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.

[Bilge]

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.

[mbabker]

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.

[Bilge]

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

[mbabker]

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

[Bilge]

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

[mbabker]

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.

[mbabker]

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