Today we have 15 opened pull request and 11 opened issues.
But we have no reaction of comunity.
Last merge was 4 monch ago.
Unit tests have errors.
Tests for Oracle not support.
Version 3 not activity since 31 Dec 2019.
What is the future of the project “laminas-db”?
If the development of the project is not planned, then you need to look for a replacement (for example, Eloquent from the Laravel project).
In that case, why use Laminas?
Thank you for your answer.
But you dont give an clean answer. What will be, if maintainers non active? How long it?
Dec 2020 were “laminas-db” Maintainer Vote.
We have 15 opened pull request and 11 opened issues.
We have 3 non active mainteners on “laminas-db” project.
Last merge was 4 months ago.
Version 3 is not developed since 31 Dec 2019.
Unit tests have errors.
Volunteer developers cannot complete the quest with CI on github and stop making contributions.
For example, in laminas/laminas-db#232, the comment was changed, but the test failed!
Give us local instrument for run tests (the best is Docker images on official repository).
Tests for Oracle are not support on CI.
Marco felt that the original reason to re-open laminas-db was likely driven by Zend to allay customer concerns, likely around IBM DB2.
Matthew said he couldn’t comment, other than to say it wasn’t really about DB2.
He indicated he’d spoken to the maintainers, and they were in a situation where they each want to help maintain the library, but that their jobs keep them too busy to do so.
Matthew’s primary concern is what happens to existing users (there are a LOT of package downloads, and it’s a key part of Laminas API Tools).
For him, having a migration path from laminas-db to Doctrine DBAL would be ideal, whether that’s a wrapper (easiest for adapters and basic queries, difficult for SQL abstraction), or some sort of migration tooling (which hits on the SQL abstraction difficulty).
We opened votes then to:
Remove the current laminas-db maintainers
Mark the laminas-db package as feature-complete, with the exception of adding support for new PHP versions
Both votes passed.
We decided that any migration tooling or wrappers would require an RFC before making further decisions at this point.
Just a question,
for new projects we should use another DB component ( for example doctrine ) Instead of laminas-db? or use laminas-db and in the next months, you will be updating it and it being alive?
What is your suggestion?
As far as I am aware, “feature-complete” laminas packages only receive updates to support new PHP versions.
Ultimately, laminas-db will not be receiving any updates beyond security fixes and compatibility updates until the “feature-complete” mark is removed (which might as well be never).
(Take this with a grain of salt please, I am not a maintainer for the laminas project )
Heyo, laminas/ maintainer here: precisely what makxk said.
This means that we won’t put improvements in the projects besides:
keeping it running
security maintenance
In order for laminas/laminas-db to receive new features, improvements and refactoring anything, we need an active maintainer that owns changes applied to the project.
Without such a maintainer, the architectural vision of the project is not there, and any changes landing it it would mostly be “random”, or perhaps just generate chaos and instability.
After a short meeting in our team, We decided to move to doctrine, Just it’s good if you can update laminas docs (for blog and album modules) and replace laminas-db to laminas or add laminas example too. it’s helpful for new users
makxk send some does for me to use doctrine in laminas,
I’d suggest sending patches to upgrade the docs: it’s not a question of just “adding examples”, but requires careful planning and work, and laminas/laminas-db is mentioned in a lot of places.
Please remember that this is an open-source project, so you are part of the community here