Hi folks, I took the liberty of creating a new category “Neos Project Decisions” (until we have a better place or decide stay with this approach).
We’ll need to discuss and take a decision on the vendor namespace (that is, the technical namespace to be used in code, primarily PHP / Composer) which we are going to use for packages created and maintained by the Neos Project.
Before we start voting, liking or plus-oneing suggestions, I would like to open the discussion about pros and cons of the different options. If there’s no discussion needed, please also state that you think so.
To put this into a context, we are currently using the following names
Neos CMS / #neoscms
Neos
Neos Project / neos-project
Flow Framework / #flowframework
As far as I’m concerned, the possible options for the vendor namespace are:
I’m not sure how pressing that topic is but if we rename all package keys we should IMO take the chance to (re-)evaluate some of their names. “Neos.Neos” is not so nice for example.
Some ideas from the top of my head:
TYPO3.Neos => Neos.CMS
TYPO3.TypoScript => Neos.FlowScript - or something else except for “TypoScript”
TYPO3.TYPO3CR => Neos.ContentRepository or Neos.NeosCR
What about TYPO3.Kickstarter and TYPO3.Neos.Kickstarter? Maybe they could be combined into Neos.Kickstarter with some kind of extension mechanism. Or Neos.Kickstarter.MVC and Neos.Kickstarter.Site… Mh…
In fact it would be consequent to rename TYPO3.Flow to something like Neos.Core, but that might go a bit far…
Besides we could deprecated the Upper.CamelCase keys in favor of the composer naming style if we rename them…
I think it makes sense to think a bit further into the future like you suggest, @bwaidelich. As soon as we have taken a decision on the vendor namespace we can then plan the next steps, and we shouldn’t try to take all of them at once, I guess.
Renaming TYPO3.Neos to Neos.CMS (well, Neos.Cms) makes a lot of sense. But I think TYPO3.Flow to Neos.Core is a bit over the top.
So, Neos.Flow sounds a bit weird.
It’s not said of course that we can only have one vendor namespace. We could certainly introduce “Flow” as a vendor namespace (but there’s a web agency using that name on packagist.org). If we did that, we’d have Flow.Core, Flow.Http and such - not a bad namespace.
Like already posted on Slack I like the idea of the Neos vendor.
Whether it makes more sense to have something like Neos.Flow oder Flow.Core I personally can’t really decide on. But both sounds fine for me…
I don’t really like NeosProject as vendor as it is quite a bit longer and we have a nice short name - I would think that it makes sense to stay with that. I also think that all examples given like Neos.CMS oder Neos.NeosCR sound fine.
As we also use Neos as main product name and for example for the domain and due to that for several services like Slack, Discuss, … it just fits well into that kind of naming scheme.
For Neos, let’s use the Neos namespace, and use @bwaidelich’s suggestions for the package names .
Neos.Cms
Neos.NeosCR
In the longterm, I would like to see the kickstarter stuff reorganized, but we should probably refactor only one thing at a time, and that’ll be a lot more than just a renaming. That and a potential rename for TypoScript should probably go in another topic.
Like @robert, I don’t think it’s a good idea to rename Flow to Neos.Core or Neos.Flow.
We could also go with Flow.Framework which would give some nice visibility to anyone looking for “framework” on packagist.
If we did that, would we need to ask flowsa.com if they’ll move their packages to FlowSA or FlowCommunications? I’ll draft an email about that. (FYI Their flow/jsonpath package has 29k installs with 11k in the last 30 days. typo3/flow has 117k installs with only 6k in the last 30 days)
Another gotcha with the Flow namespace is the github user Flow is already taken: Facebook Flow · GitHub
Or what if we repurposed the “Flowpack” namespace? (TYPO3.Flow => Flowpack.Core or Flowpack.Flow)
Or perhaps: FlowZone, PhpFlow, FlowPhp, …
The content repository’s package key could just be Neos.ContentRepository. And nitpicking on the Neos.CMS key: it should be Neos.Cms in order to be consistent with our naming rules.
We saved the “flowframework” organisation on Github for that purpose. I wouldn’t use Flowpack for that, since that would practically mean renaming the product.
I’m not sure yet about how to approach Stephen with our request. I think it must be super-humble and friendly because it’s a hassle for him and we have no real privilege to use that namespace (other than it makes sense because we’re an Open Source project).
for me, I don’t have hard feelings regarding the vendor namespace, although my personal perference would be:
Neos as namespace for everything
Neos.Neos, Neos.Flow just sounds fine to me. It’s the same many other packages use AFAIK.
I don’t really have clear arguments in favor or against this; but that’s just my personal feeling. Basically I can live with any decision you people make; but I’d prefer shorter namespaces despite longer ones; so -1 to NeosProject etc.
I think we should take a decision soon (now?) regarding the vendor namespace in general and PHP in particular.
We can still discuss the individual package names in a separate thread, but for now I’d like to open the following poll:
Should we use “neos” as our vendor namespace in PHP code and in Composer, for Neos, Flow and further products?
Examples would be “neos/flow”, “neos/typoscript”, “neos/neoscms” or “neos/neos”, but as mentioned above, the second part of the name (the package key) is not part of this voting.
Also, we could think about getting rid of the individual sub-language names (eel, fizzle, …) while we’re at it, because beginners don’t get the distinction anyway.
I think that was suggested already, I find Script still not a good idea. Also EEL definitely is separate from TypoScript and should be treated as such. fizzle can be hidden as technical detail though. FlowQuery maybe as well, although it is somewhat important to understand the context.
I don’t think it’s a good idea to blend TS, EEL, fizzle and FlowQuery into one coupled soup. Each of them has its own prototype after which it was built (JS expressions, CSS attribute selectors and jQuery), which makes learning them a lot easier. The sooner beginners learn to see the difference between them, and that you can actually use them independently one from another, the better for them.
