The discussion today was attended by @ahaeslich, @bwaidelich, @christianm, @Marc, @lubitz, @sebobo and @wbehncke.
Here’s a brief summary of what we’ve discussed and decided on:
We have taken a look at what points that were raised in this RFC need to be decided before the release of Neos 9.0. We talked about two major decisions:
1. Do we want to split Neos.Neos
into a meta package (requiring all other parts of Neos) and a core package (providing the Neos domain concepts)?
There was general agreement that establishing a dedicated core package would be a sensible move.
@Marc and @christianm suggested that a potential meta package could also occupy a different namespace, so that we would not have to change Neos.Neos
’ role.
@bwaidelich remarked, that the designated function of such meta packages (bundling dependencies) should rather be fulfilled by distributions or an installer mechanism.
We reached the conclusion that - for Neos 9.0 - we can essentially stick with the status quo. Neos.Neos
shall require all split-out backend module packages - we can treat Neos.Neos
as if it already was the intended meta package. Moving concepts away from Neos.Neos
into a new, dedicated core package can be done independently (and may even be postponed to the post-9.0 phase).
2. What should the future of our repository structure be?
We have discussed the two major options that have already been outlined in the RFC thread:
-
Do we want to establish a
neos-ui-development-collection
and move all backend modules there? -
OR: Do we want to merge
neos-ui
intoneos-development-collection
?
After considering both options, the meeting was generally in favor of merging neos-ui
into neos-development-collection
. Although this will loosen the structural boundary between UI and Core code, we considered it a significant advantage to be able to develop both code bases in unison. It will be easier for us to reach the desired clean architecture, when we are able to move both sides of the equation at once. In the future, it will still be possible (potentially even easier) to create a third dev collection, should we recognize the need for it.
The question remains whether it is feasible to perform this merge before the release of Neos 9.0.
@christianm offered to conduct an experiment, by performing the merge and examining the resulting unified repository locally. Based on his findings we will then facilitate a team decision on this question.
@bwaidelich pointed out that while we’ll have to figure out how to reconcile the CI pipelines of both repositories, we should cease the opportunity to get rid of the Neos.Neos.Ui.Compiled
package.