Hi,
I see from the change log for 4.2.1 that:
Can we have a little more information about this decision? This seems like a lot of work for the Omeka team to be taking on, is there any support from the wider Laminas community? Is this an interim measure or a long-term commitment? Most importantly, what are the security implications?
Thanks, and good luck!
John.
So, the reasoning there is that those are all packages that Laminas itself decided to abandon further development on. I posted a tracking issue on our Github listing the affected packages and how we’re dealing with them.
These aren’t necessarily permanent and total dispositions; some packages have alternatives we might use instead, some can be dropped entirely. And forking provides us freedom to do things like pare packages down to the parts of them we actually depend on (as an example, the mail package has a lot of code for checking/receiving mail that we could remove), make our own changes and fixes in the library if necessary, and sync PHP version support to what Omeka itself requires.
In general these are packages that saw only strictly necessary maintenance updates for things like new PHP versions, so taking on the maintenance of these isn’t particularly burdensome, and in many cases having direct responsibility is actually easier than the situation before. Our focus, and the reason these switchovers can happen in a minor point release like this, is on having no compatibility issues for any users or developers in our ecosystem.
On security: these do become part of our responsibility, but security of the dependencies is already part of any project’s responsibilities anyway. And like I noted above, being directly in the driver’s seat isn’t a bad thing.
Here at the University of Rochester, we’re using 6 instances of S, and have concerns about the long term maintainability here. We have a few developers, myself included, who can assist with maintenance/ the development push necessary to move off MVC entirely, but we do need direction. We would love to open a dialog with the Omeka team about what management of MVC looks like, and how we can better assist the community. We love Omeka, and would hate for it to be dependent on abandoned infrastructure
I really don’t see it as an area of concern.
Just to reiterate my points from before: this is a “boring” component. Years of releases back to 2022 at least and really further back have been simple handling of PHP deprecations and other version support changes. This is a positive both in terms of the likely amount of necessary maintenance work, as well as indicating a component that’s just feature-complete. This is something that’s fundamental in that it’s the basis for Omeka S’s web responses, but we don’t need it to be interesting and fresh.
Beyond that, I’d add we have years of experience with Omeka Classic successfully maintaining the Zend Framework 1 libraries, the predecessor to Laminas. Maintainability is obviously a huge interest of ours: we directly maintain the core itself, nearly 50 modules, 9 themes, and a fleet of instances, to say nothing of the universe of Omeka S installs in general. Long-term maintainability and sustainability is a core concern and focus for us, and this isn’t an unconsidered or short-term decision.
I of course appreciate people having an interest in Omeka’s future, and willingness to help and get involved, but this just isn’t an area I think a change is warranted.