I think we are decided that the NodeTypes package(s) are not really best practice and we want to get them out of the “default” package set. To that end we should extract them from the dev collection. I think that’s an OK breaking change to the collection as the single packages do not break at all.
That’s the first point I wanted to gather feedback on. Do you feel it’s ok to “break” dev collection in that way? If someone installs dev collection and relies on the NodeTypes package they should have declared it a dependency and it would just be pulled separately, so that should be fine still…
Secondly as the inline editor config changed it should be adapted in the NodeTypes package. As both configs do not work together and are not compatible, this is definitely a breaking change to the package, but also something you definitely want for newer projects with the NodeTypes packages. So therefore I would suggest that right after extracting them (or lets say aligned with the upcoming release) we split a 4.1 branch (in line with the upcoming Neos release) and then immediately merge the chnage for new configuration to master and make it 5.0 so that this package has a higher version number than the rest of Neos but you as integrator have a concious choice of new or old configuration.
That’s the second thing I wanted feedback on, does that sound sensible to you? Any objections to this plan?
I don’t think I understand 100% of what you wrote, so let me ask some stupid questions:
Regarding the NodeTypes packages:
Removing them from the dev collection would not mean that they are also removed from the base distribution, correct? “Breaking” the dev collection, which is used by contributors only anyway, sounds totally OK to me. Removing them from the base distro however is something I wouldn’t recommand as I think it would totally confuse new users.
Development on the nodetype packages would then in the future happen directly on their repositories, as opposed to within the dev-c currently. Will that not make our release much more troublesome, as there are even more packages to create releases for (never done a release myself, but I understood this was one of the current issues)?
Re Inline Editor config:
I’m not too happy with version numbers diverging, but we have that for other packages as well, so I guess we can live with it. Most integrators probably won’t care, but will just use what’s in the base distro. That would then mean that we can release NodeTypes changes independently from the Neos core, and will just include whatever is the latest stable version in the base distro for each release, right? Or would you want to stick to the same release cycle?
Removing them from the dev collection would not mean that they are also removed from the base distribution, correct
Correct, they would stay in the base distribution of course, at least for now and until we decide to remove them there (which then would be a breaking change)
Development on the nodetype packages would then in the future happen directly on their repositories
Correct, and yes it makes releases more complicated, on the other hand I would assume the NodeTypes packages won’t get THAT many changes in the future.
That would then mean that we can release NodeTypes changes independently from the Neos core, and will just include whatever is the latest stable version in the base distro for each release, right
Especially with the point above, I don’t expect many changes so we might just keep the old and new branch alive for quite a while without doing many releases.
Totally agree with everything, only thing that comes to mind are tests, since many of them rely heavily on those node type configurations. But should all work out if by “extracting” you mean exporting them to a separate package, but still keeping them in as a (dev?) requirement.
Or export only some needed NodeTypes in a very rudimentary manner to Testing/NodeTypes.yaml?
I’d like to again question whether we really should pull them out of the dev collections.
I see the following reasons against it:
I personally rather see it beneficial if we release a bunch of packages with locked versions:
This way, it is trivial to determine if you have a consistent system. I think it is already complicated enough to explain the differing Flow and Neos versions in the ecosystem. On a sidenote, I’d even be fine with raising the Neos version to the Flow version with the next Major release to have this cleaned up.
I fear that we end up at a situation like the the Eclipse Project where every package has a different version thus it is extremely difficult if things are supposed to work together
I know this is not “SemVer” applied to the package level; but to me the benefits of seeing what fits together is much huger. You could solve this with package constraints (theoretically); though I think this is a huge maintenance burden. (and there is no good way to see that a given set of package constraints is actually correct, now and in the future when new versions are released)
regarding transitioning to the new Editor Config
IMHO we could fix this in the Neos UI. Instead of deciding whether to use old or new config, we could merge them together. This would remove the breakiness IMHO and we can gradually migrate to new config without people’s instances breaking.
I would not deprecate the NodeTypes package, as to me, it is a crucial component to the Neos first run experience
To me, it is a lot easier to explain “you can start with these node types, which you probably need and add the ones you still need specifically”, versus “you need to create everything from scratch”
I think we must help people make a conscious decision between “you should start from scratch” vs “using the NodeTypes package is a welcome shortcut”. In many of our smaller projects, we have the Node Types package included because it is just convenient to use.
I’d love if we could make the NodeTypes package more modern; e.g. move all Fluid based rendering to an extra package; and switch to AFX based rendering.
It’s just my two cents Sorry for bringing up this discussion at such a fundamental level again
I have a comment about the “first run experience”:
It would become worse if we removed Neos.NodeTypes without substitution, but in my eyes this was always rather the job of the demo package, which we all talked about updating on numerous occasions but has not happened yet
So after Neos.Demo receives the long overdue update, I don’t see this as an issue anymore, since you’d have an even more valuable starting point ìn my opinion than the (current) Neos.NodeTypes package.
I think the Neos.NodeTypes package is easily misunderstood as “necessary base requirement” when starting out.
It’s been a couple of years since I started working with Neos and maybe we could get the opinion of some newcomers what their experience was and what helped them most to get their first project off the ground.
I agree with all the points @sebastian brought up and personally am not in favor of deprecating the Node Types package. It’s a little bit a decision of continue to provide an “out-of-the-box” experience or further go into the bring-your-own-batteries direction.
I totally see the advantage of projects working with only custom node types. That’s the ideal project for me – starting with a content strategy approach, content modeling and so on. But if we only go that way, we miss out the non-ideal projects which try to get a website pinned together based on best practices.
If we move everything to the demo package, even more production websites out there will have the demo package using actively. That’s a big problem and I see it from real world projects everywhere: it’s crazy how many still have the Flickr plugin and demo user registration enabled on the live websites …
Sorry for bringing up this discussion at such a fundamental level again 
