the title says it all, so TL;DR: I would like to integrate the Neos.Ui into our neos-development-collection for the next major release (Neos 6.0).
I haven’t really thought it through yet, but I think this would greatly simplify our core development and release process.
One risk I see is that we create a tighter coupling this way by accident¹.
But if we’re careful it can even ease the process of untangling the two worlds. For example we could replace the UI routes at once and avoid PRs that depend each other²
Another consequence would be version numbers that stay in sync – or to put it less positive: We’d have to create a new Core Release if only the UI needs an update vice versa.
I don’t think that this is an issue, either. We usually wait with releases anyways until a couple of new fixes/features are merged (except for critical bugfixes of course).
But before I get more into it – I think that we discussed that before and maybe there are really good reasons against going this route.
¹ The UI repositories would still exist but be turned into readonly mode like the other subsplit packages. that way we could push changes to the Neos “backend” and the UI parts simultaneously thus making it easier to blur the line
I already wished that for the last Major release and I am still in favor of merging the UI package into the dev collection.
Back then, I discussed it with Dmitri and as I remember this were the pros and cons:
Pro:
PRs for new features do not need to be done and coordinated in two repos
Within the dev-collection UI PRs are more visible and get the chance for more reviews
With that, new contributer may be attracted to the UI code
There is still some rough PHP code, which should be cleaned up and refactored.
Cons:
Release cycles are bound to that for Neos and the development would get less agile (well in the meanwhile the UI code is much more stable and feature releases of the UI are pretty much in sync with that of Neos)
Back then, we agreed on, that it would be best to have a clean and well defined interface (like GraphQL) to the CR and nearly no PHP code in the UI package, which would make the need to integrate it in the dev collection less significant.
I’m fine with integrating. The “agile” development phase is over IMO.
We just need to make clear how development for older versions works and what needs to be done to make running the tests etc. work again.
I assume it will be a pile of work for the next release.
Have totally missed the thread. As I work mainly in the UI I am not so familiar with the regular release process and I am bit afraid of doing a Hotfix like the issue from the UI last week 4.0.11.
So in general we don’t need to agility anymore. Because we are more or less stable in the UI.
But with joining the repositories we will have a really huge code base in one repository.
A matryoshka of neos
If the team decides to merge the repositories I am in for it but we need to adjust the circle ci stuff. Or need to find a way to unify the actual CI handlings. If I am not wrong the regular neos development collection uses travis and the ui uses circle CI.
So the decision has also an impact for the devops people of the team
Phew, we discussed this a few times already and I forgot most of it again. But I have the nagging feeling we decided against it multiple times for a number of different reasons, last not least the uncertainty whether it would really make things easier.
Ideally the UI would not contain custom PHP code but use a defined API on the server side. Done. Of course for new things you might need additions to that API, but that’s life.
Another point coming up is the “the PHP folks are not seeing the UI package” – which should be “fixed” by raising awareness for the fact that PHP code indeed exists in the UI repository.
Third point: Yes, we keep versions (or rather branches) in sync now, but that’s mostly for eaasier understanding. Having different patch-level releases (as is possible now) is a bonus to me, and would no longer work with a monorepo.
That’s a great point… There’s a lot of code in the UI package currently that should have been in the Neos distribution vice versa.
If we put it all in one distribution we should do that in order to change this situation more easily not to increase the interdependencies even more. And once we have a better distinction we can (i.e. should) split the repositories again.
Right… I’m not sure what that really means in terms of work… How did we solve this when we merged the Neos & Flow packages?
Maybe I’m being naïve but IMO triggering a (patchlevel) release should become as simple as clicking a button in any case. Worst case: A Neos bugfix update does not contain any changes (like today with all the readonly sub repositories). Best case: A buggy release is prevented since it was easier to test everything in conjunction
OK, well… Who is “we” in that case? Were did you discuss this multiple times? what were the reasons to decide against it? Did the situation change in the meantime?
As I wrote above, I’m not perfectly sure if this is the right way to go but I’d like to bring up some pros and cons to change that and to turn “nagging feelings” into explicit tendencies.
Absolutely! And IMO a monorepo would make it easier to go down that path because we could move code in a more “atomic” way.
To be honest this was exactly my point of view when we decided to create mono repositories for the Flow and Neos packages.
In the meantime I think that it was the right way (at least for the point in time) and that it saves us from a lot of extra work.
Just to let you know: I won’t push this topic any further (at least not for Neos 6.0) since it seems quite a lot of work (e.g. circleCI vs travis, sub-packages, …) and I already have enough on my plate.
I still think that we could greatly benefit from a single repository (though I can also see the downsides), so I’d be more than happy if anyone would address that.
Maybe it would be a great topic for a sprint. So that a team can work on it.
And as @bwaidelich already mentioned it is a lot of work to streamline the CI stuff. Because for some reason the neos-ui seams to do everything in a different way …
