Returns package name to laminas/laminas-db so an vcs override can be … #31
Conversation
…used to load the package from github instead of just locally. Signed-off-by: Joey Smith <jsmith@webinertia.net> Signed-off-by: Joey Smith <jsmith@webinertia.net>
|
I'm trying to understand why you did it this way instead of keeping the alternate name and adding That would have had the benefit of allowing to simply require this fork instead of having to resort to a VCS override (which I would guess becomes much slower as branches and tags are added, as opposed to retrieving everything via Packagist). |
|
Please see this issue. We can not release via packagist while using the same vendor name. Plus, its frowned upon to keep the original providers namespace if development is going to continue outside of the laminas team. The issue I linked explains the rationale. The code you are seeing here is truly only intended to be used by those of us that are working on the package. |
|
First of all apologies if this now turns into a lengthy discussion. Please let me know if/once you feel this should be taken elsewhere. Also this is of course your fork so you can do whatever you want. As I already explained, I just wondered whether you maybe did not know about the That said, I understand that you cannot use Packagist for laminas/laminas-db. Which is exactly why I wondered why you did not go/stay with axleus/laminas-db (which you can publish) but at the same time, maybe only for the 2.x releases, add a While laminas/laminas-db may be in security only mode or whatever it's called, I feel it's essentially abandoned/discontinued and people like me are searching for a replacement - ideally maintained, but at the least fully functional and compatible with PHP 8.4. |
This is what we are working hard to provide. Just understand there is only a few of us. Just three in fact. While I agree, we could have kept the vendor name etc as it were that still would not have addressed us continuing to use the Laminas namespace in a fork, which we should not. Long term that does not address all of the goals which is to get the package updated to new versions, reduce the maintenance burden and provide satellite packages. All in support of the primary goal which is to have the component set back to active development under the laminas organization which in the long term will provide the most stability for users. The entire point of this work it to prevent the component from dying. There has already been a HUGE amount of work done and we intend to see it through so whether the component lives on under the laminas org or remains a fork only time will tell but the component is not dead. That we assure you.
As I said, that still does not address the fact that we would be using the Laminas namespace in a fork. The laminas team is aware of our work but we feel that the entire over all process will be a lot smoother if we do not try to release a package in this way. The laminas team policy is that outside code, even when developed by their team members, should not use the Laminas namespace. Only code maintained by their team should be namespaced Laminas. So to cut a public release of axleus/laminas-db all of the namespaces would need to be changed. Then what happens if the team decides to pick the project back up and bring laminas-db out of security only? With all things considered we have chosen the path we are now on for better or worse. If all goes well we will know pretty soon which direction things are going to go and we will move forward accordingly. Hope this helps clarify why we have made the choices we have. |
|
Also, feel free to start a discussion here if have any more questions or suggestions :) |
…used to load the package from github instead of just locally.