Hi folks, Neos 2.0 and Flow 3.0 are out, the Github move practically happened, so it’s time to think about Neos 2.1 (and Flow 3.1).
As discussed during some hangout recently, @aertmann , me and of course many others of you suggest that we introduce a much clearer and more structured release cycle now that we started with “phase 2” of Neos’ product life cycle. I’m not sure if we can or should discuss and agree on a definitive release process here in discuss or should just collect ideas (in a separate thread) and then discuss / decide on it during the next sprint in Frankfurt – any opinions?
But no matter how we get to a better release process, we shouldn’t wait with planning Neos 2.1 until we have the new process. I think we could already have a few major features ready which would justify Neos 2.1 in a month from now. We need to agree on answers for the following soon:
which key features are must haves for Neos 2.1 / Flow 3.1?
Thanks for starting this one @robert, it’s very important we work more as a team on prioritized features to improve our workflow. Started a separate thread for that discussion, so we can use this one for collecting and deciding on features for the release. See Optimizing release development workflow for Neos/Flow
Btw. the Github move is only half way done as I see it, maybe even less. Development of 2.1 can of course be done independently for a while, but currently we’re in limbo as I see it. Finalizing this should have a higher priority than working on the next release.
Additionally I see we need to focus more on stuff around the product, which the release of 2.0 allows us to do. We need to grow adoption & contribution. Personally I think that’s more important than product. For this we need to work on our website and communication in addition to easing the contribution workflow and on-boarding of new contributors.
Here’s what I can imagine the next releases could include (not in any particular order or prioritization):
Neos
Every release (step by step)
JS/CSS refactoring
UI improvements
2.1
Finalize history module
Finalize content security
Workspace workflow
Asset replacement
Allow uriSegment to be empty for default presets
Help texts
2.2+
Native sorting/filtering (CR)
CKEditor
Developer tools
TypoScript browser/debugger
Node type creator
Command module
Logging module
Internal search (documents, content, media + extendable)
“Red carpet” (this goes beyond installation, means also things like extended node querying without Elasticsearch or improved developer tools especially for TypoScript / Content cache)
Performance improvements
I can’t say how much in terms of the JS refactoring can already be done so that would be optional.
I can definitely contribute the Workspaces part (that means: collaboration / workflow related features for workspaces). Much of it is done / merged already, but I also have more planned for the next 2-3 weeks.
Recently @dfeyer and I discussed the red carpet topic, which made me unsure if it’s worth putting a lot of effort towards. In general Flow runs just fine if you have a setup suited for it’s needs. This kind of setup is difficult for people that have restrictive setups to achieve, thus many shared hosting solutions face problems. However considering our target audience, which I see as professional developer agencies/freelancers doing custom web solutions (maybe we disagree here). It would be much easier to accept those requirements, since it’s how Flow was built, and instead give clear and good guidance how to get a working setup. This means delivering a officially supported docker image and explain the requirements in a clear way. If someones hosting setup is not compatible with it, then they should consider finding one that is and we can help providing options that we know are compatible. This is achievable with very little work and might cause a few people to decide against it, but I think the majority would be just fine with it. We also require PHP 5.5 and using memcached or redis if you have anything larger than a small site. These requirements are totally fine, but they need to be communicated so people don’t start out, waste a lot of time ending up finding out their setup isn’t compatible. This is probably not a popular opinion. But it will mean the team can focus on improving the product, instead of compatibility with tons of unpredictable setups, which will be a lot of work with no gain for everyone already running it just fine with compatible setups. I think that adds more value to the project than the alternative. Would like to hear some more thoughts on this subject.
I think that content revision history would be an important feature. Large multilingual sites with many content editors would benefit greatly from the possibility to undo content changes.
I think that trying to adapt the software to run on every kind of shared hosting setup is a lost cause and the hours should be spent on creating an easy way to deploy a working setup that meets the requirements. The cost of running a basic server on one of the big providers is a few $ per month so the need to use shared hosting for a Neos project because of the cost really is not there. Also, it is possible to setup shared hosting that meets the requirements pretty easily (tried that) if you really need it.
I share the @aertmann vision, the red carpet project need to be a realistic project, focused on documentation, explaining requirements.
Providing an official docker dev setup can help new comer, and respect the vision that we share about software development, making things easier. I think before starting / continuing the red carpet project, we, as team/community, need to define to target of Neos, and everything else should follow this audience.
I think solving the dev setup with docker can be quiet easy we have some docker expert in the team. The next step should be to give some guideline for hosting Neos project. We give a workshop for a small agency here in Switzerland who use mainly shared hosting before choosing Neos, during the workshop I help them setting up and nice ansible workflow to provision VPS. Maybe we can give instructions on how to setup on Linode, Digital Ocean or Heroku, based on high quality configuration. Maybe the dev setup can be done with Packer ( https://www.packer.io/intro ) to provider also VM image for different technologies.
For the publication workflow, I thinks it’s the key feature of 2.1, we don’t need a lots more, but we need to have a really polished feature. We are a small team, and we can not work on multiple big feature at the same time. We need to release more often, we discuss about this in the past, one major feature === one release, and the team need to be behind this feature.
@robert One frequent question from our clients, is to be able to send a link to preview some page (for boss review, …) with a token valid during X hours. For the first version of this feature, the editing can be disabled, let’s have some feature for the next release This link can be send to people with Neos account, just for review of a single page.
@robert@kdambekalns and me also discussed red carpet this weekend and came to similar conclusions. Focus on documentation and providing a good entry point by having a solid VM/docker whatever to download but do not try to do stuff like web compile.
I will follow up with some more points I have on my mind.
I’m in personal contact with Alexander Lisachenko https://github.com/lisachenko from GO AOP, an other PHP AOP framework, inspired by Flow AOP. He’s intersted by a collaboration on the debug proxy. He use lazy compilation, and look like it work nicely, so in the mid term it should be intersting to have a collaboration with Alexander on the topic.
Okay, I see that as a misunderstanding then because I didn’t especially mean only the installation/hosting of Neos with “red carpet”. I still see many things being not very convenient or sometimes (very) hard to debug when using Neos as an integrator or developer. So some of that is tackled by “Developer tools” but I think we still have to go beyond that for some topics.
I’d prefer to work on the structured editing as soon as possible, but it’s realistic that it goes hand in hand with the “flexible user interface”.
I’d also like to add something like “Multiple content sources” to 3.0+ which might be related to “Import/export API” but goes beyond it.
My biggest concern is, that we would push important, larger topics to 3.0+ because there’s already quite some features in your list for 2.2+ that are nice to have but don’t need to be part of the core (e.g. integration of services / responsive preview). So we have to prioritize that list in order to have enough resources to work on “larger” topics for an upcoming 3.0. While I’d very much prefer to include all backwards compatible features already in 2.* (with feature switches or deprecations). Otherwise we might end up with a long timeframe / lots of merge problems until the first 3.0 release.
thanks for the discussion I just tried to catch up a little and wanted to share my personal plans:
For the time after 2.0 (which is now), I’m planning on working on the CKEditor Prototype more in-depth;
and hopefully get it to a state where it is workable quite soonish! I am not yet sure when we we will be
able to ship this, but I’d like to work in this area.
For me, this is also an important intermediate step towards structured editing, which @christopher has mentioned
and which also has an extremely high priority for me.
just a little note from my side. We’re currently building quite some REST-Services in Flow, so this would be a field of interest for me. Well, and obviously I’m in for finalizing content security
We just had a discussion on this topic during the sprint and came to the following conclusions:
We came to the conclusion of selecting a couple of features that together make the feature freeze. When those features are finished, no more features will be added and a beta release will be planned. This means that no fixed release date nor feature freeze date will be announced, but following the progress of the selected features will give an idea of when a release is finished.
We decided not to have a single release manager for releases, but rather make it a project for one of the cross-functional teams.
The features will all be projects that are assigned to teams to ensure their finalization.
Features:
Workspaces
Content security improvements
History module polishing
Additional minor features:
Integrator improvements
Tooltips (UX)
Help texts (UX)
Performance improvements
We expect those major features to be finished in 6-8 weeks.
Participants: Robert, Christian, Rens, Daniel, Aske, Alex, Gerhard, Hans
These features are what we think is realistic currently.
This link can be send to people with Neos account, just for review of a single page.
I just tried to catch up a little and wanted to share my personal plans: