The neos/diff package is completely independent of Flow and Neos, in fact it doesn’t even need to be installed as “Flow” type package but could as well be a library. It hasn’t changed since initially introduced. I think it makes sense to move it out of the collection and maintain it as a separate package.
1 Like
Separating this package from the development collection would mean:
- we signal by that that this package is important enough that the Neos team takes responsibility for its maintenance as a standalone package. Which I personally won’t - it’s just a helper package for Neos and if I find a better solution, I’d like to drop this package and use a different one.
- we need to adjust release scripts etc. for this to be released separately, and in sync with Neos
Personally, I don’t think that it’s a good time investment to do this separation. Apart from cleaning up the dependencies, do you have other reasons for this proposal?
we signal by that that this package is important enough that the Neos team takes responsibility for its maintenance as a standalone package. Which I personally won’t - it’s just a helper package for Neos and if I find a better solution, I’d like to drop this package and use a different one.
I see it differently, we split the packages anyway, so there is not different visibility involved. And to me it means we (can) have a different maintenance cycle for it. In this case it could probably stay version 3.x for a long time because just nothing happens there. I don’t think “not in dev collection” === “fully maintained standalone package” especially the outside world will not see a big difference if you don#t know our workflow.
we need to adjust release scripts etc. for this to be released separately, and in sync with Neos
I think the change is minimal and after that we have one package less to think about in the release scripts, as we just require some version of it for ever and ever until something really changes.
So for me it’s about cleaning up, defining that this is out our maintenance focus and removing clutter out of sight.
I think the (probably relatively) short time investment is worth it in the long run.
We really need to improve in this area, if it’s decoupled, let’s do it completly and release it as a separate package. Or we can stop creating small decoupled package, continue our way to a big monolith, …
for @christianm here, it’s not tons of job, and a good move in the good direction.
In a near future, I see other package, bigger one like EEL, that can follow the same path, decoupling in a default PHP package, that can be used by other project, framework, and create separate release cycle. This example will cost us a bit more, I think the maintenance of EEL is not that big, but it’s really something that we can share with other community.
2 Likes