Neos is a great tool and many super smart people develop it. In many areas Neos is superior to other popular CMS and there are only a few weak points.
So while all of this is great each “stable” version of Neos has a big list of often very obvious bugs, a few examples from the top of my head:
Neos 3: The main navigation item “Media Browser” has no label
Neos 2.something: Delete a published document node, and Ember shows an error, cause after deleting it can’t reload the page
Neos 2.something: Create a document node, without publishing delete it. Publishing is broken.
THIS IS DEVELOPERS AND USERS FIRST EXPERIENCE OF NEOS. Something cool, which is broken.
I feel a strong need for proper release testing. I don’t have the answers, but I hope I can help here. A must watch is this video here, the first half shows the effect of proper release engineering at Mozilla: https://www.youtube.com/watch?v=7j0NDGJVROI
What’s your opinions here? How are you handling this issue right now?
I’m sure this is something we can fix together over the next month.
Good wrap up, and you are right these things happen.
I think they are acceptable in open source, but I would be more than happy to avoid them. I guess more tests on the UI side help as well as people that actually beta test. We started to skip betas because we didn’t really get much feedback back then.
IMHO we as a team are stretched thin enough as it stands, so I don’t see a big investment in UI tests and Release Engineering happening unless we get help, ideally experienced help.
If I can help to facilitate this I am more than happy, but I also cannot commit on anything in that direction.
As @christianm already said, much of that is true.
Including, and that is where I again stress we need help: the dev codebase lacks testing. And often enough people come across something and do not report an issue afterwards. And fixing those things could need help, too.
Anyway, can you explain the first example or point me to an issue about it? I checked and cannot find what seems to be missing… As for the other two: 1) it should just go to the parent node, that is what it did for “ages” now. No more? 2) Is this what we fixed with 2.3.8?
Again: if there are bugs, do not “report” them here, on twitter or via Slack–create issues instead. And when talking about bugs, link to the issues. If no issue exists yet, go to step 1.
As far as “fixing the issue over the next month” goes, not sure there is any value in promising anything. As already pointed out, with (experienced) help, maybe something can be done. But it seems everyone has too much work, all the time… That being said: any help, suggestions, ideas, PRs, new tests, infrastructure improvements are welcome!
I agree with my previous speakers in practically all points.
We can also gladly discuss this on friday in the Q&A session at the meetup (and afterwards too ofc)
I can see how frustrating it can be from an integrator perspective, but maybe I can give you some tips how I came to terms with these common zero day issues after minor and major releases.
@kdambekalns As far as I know all of those bugs are already fixed. I just wanted to give examples… these were some fo the things I got really confused and wondering what I did wrong when I first started with Neos.
This post is NOT a bug report, this should be a discussion about improvements in release engineering.
Does anyone know how Typo3 is doing it? While we all probably think that Neos is superior, they probably have a better release process already serving so many websites…
I think the difference we have with TYPO3 is that they have way bigger userbase, thus more bug reports during beta testing. I can’t see how we can release bug-free major releases with current usage rate. For example the current 3.0 release was tested for two month by all of use, I have migrated some of my production websites in advance for the sake of better testing, but bugs still do slip through.
Given that we don’t have a rapid user base growth so far (too bad though!), I see that proper end-to-end tests could help to increase the efficiency of testing with resources we have so far. I’ll take care of it for the new UI.
