Hey everybody,
just wanted you to update on this topic that Christian and myself had a phone call yesterday on the approach, and it seems the following will work out nicely:
So we’ll experiment into this direction and try it out!
All the best,
Sebastian
Hey everybody,
we just had a discussion together with @kdambekalns, @christopher, @daniellienert where we went in-depth whether we want to go the two-repositories or single-Repositories route. After quite some thinking forth and back, we are again proposing to split to two repositories; namely because of the following reasons:
We discussed some details of the move; and we’ll try it out soon again!
All the best,
Sebastian
Too bad I missed the discussion, would have loved to join you.
Could you add some more details on what lead you to that decision?
Hey Bastian,
updated the reply above yours; maybe it is more clear now 
Here’s one more benefit to maintaining two separate repositories for Neos and Flow: In doing so, we will be setting the standard for other projects based on Flow.
When an agency has a large project that requires multiple packages to achieve the appropriate level of cohesion (and, therefore, maintainability), they should be able to use the same setup that we use: Keeping all of the packages in one repository.
Maybe we should keep that in mind in developing our composer plugin. Other projects will want to have multiple packages in one repository, let’s make that easy to do.
tl;dr: Please read the Git Repository Structure Proposal and vote at Please vote at http://doodle.com/9evuwuretertkpqm
Hey everybody,
I just took the time to re-generate the shared Neos and Flow repositories a (from my side) final time:
These should be located inside Neos · GitHub organization.
Read-only-subsplits per-package will be located inside github.com/neos-readonly organization
https://github.com/Neos-GitHub-Test/Flow contains:
https://github.com/Neos-GitHub-Test/Neos contains:
These should be located inside Neos · GitHub organization
The following packages would be versioned as separate Git repositories:
I personally have discovered https://github.com/pulls – which can show pull requests across repository boundaries, i.e. inside one GitHub organization. I think this is a totally fine way to have a great overview about which pull requests are in which package(group).
Please vote at http://doodle.com/9evuwuretertkpqm if you like this proposal or not!
I think it is fine that everybody in the community is allowed to vote here to express his/her opinion and concerns. “Binding” are the votes of the core team, though.
All the best,
Sebastian
What about the demo site? Should this be delivered with the Neos bundle or as a stand alone?
Two things:
Good point, it should be part of the “Neos” packages that are versioned together.
Short nitpick question: Why do we do a separate org for the single package repositories? Other orgs like doctrine and symfony don’t do that and I feel it makes it harder to find the single packages.
I like to move very well, but I find that some packages not in the Neos bundle should be placed.
For many applications, the packages TypoScript, Media and TYPO3CR are very important as standalone packages.
When these packages are to get only as a bundle with Neos, it is no longer possible to update these packages for other applications.
I agree with @christianm - I don’t really see the advantage of splitting it into two orgs.
Also, what @kaos said makes sense: why, for instance, Media package is in neos organisation if it can also work standalone with Flow? Maybe it should be then in flow org? I guess we might have more and more such dilemmas going forward.
IMO one organisation would fit just fine. I really like the fast search on the organisation page where you can quickly find the repo you’re after. I guess this is how plenty of us will be using it and it would be nice to have in once place.
Ack, Demo Site should be part of Neos packages.
we would release that together with 2.0? Or not?
I thought it is easier to search for Pull Requests or the repos where contribution happens when all the ones which can be contributed to are in one organization. But as the others do not have pull requests anyways, that’s possibly no big deal. So yes, we can also do it like Symfony/Doctrine and just use one org!
Nope, the packages will always be fetchable individually via Composer (see above “Read-Only Subtree Splits”) – it’s just that for developing these packages you need the full bundle. So nothing to worry about I think 
The goal is still that these packages work independently!
(I hope that also addressed the issues of @ryzy)
All the best,
Sebastian
After thinking it through again, I think the demo site should not be part of the Neos-Bundle, but I’d suggest to directly put it into the Neos Base distribution itself and version it together with this one.
Reason:
Does this make sense to you?
All the best,
Sebastian
It does. I also think that you might need to change some other stuff for Packages that do not belong to the Neos-Bundle like some new features that are implemented in TYPO3.Neos.SEO. Those changes wouldn’t affect Neos at all but the site package. I think a standalone version would fit best.
That doesn’t really fit the discussion on Ship a clean Neos base distribution without a demo package? as I see it…
Also let’s not mix the base distribution and tagging. For every release we’ve adjusted the demo site and I think we will keep doing that, so using the same tagging strategy as the rest makes sense. This doesn’t influence whether or not to ship the demo package as part of the composer distribution.
Additionally the suggested solution forces separating the base distribution from the general versioning strategy, which I don’t think is a good idea.
Regarding the question of not including the demo site in the base distribution, let’s discuss that in the topic created for that…
Couldn’t we include the base distribution in the repo too? Perhaps we could then use symlinks to help in maintaining two different distros, one for base, one for demo. We could symlink everything in Base into demo except for the composer.json.
What about a lot of other packages? It would be really nice to have Party, Form, Imagine, Neos.SEO and Setup included as well. It sounds like we’re only marginally better off with this setup unless we combine more of our packages into the same repo, even though they might not be included in the base distribution. Since some of them have a separate versioning strategy, maybe we can say that the versioning will get synced up at version X.Y (3.0? 3.5? 4.0?) and just bump all of them up to the appropriate version to get them in sync.
Hey everybody,
I just had a meeting with @daniellienert, @kdambekalns and @christianm to transfer knowledge, bring everybody on the same side technically, create a migration checklist and discuss who will do the open TODOs.
The result can be found over at the following google doc; which will be used to coordinate the migration on next Tuesday if we were able to prepare everything beforehand (which is certainly doable!):
All the best,
Sebastian
A little update, the move has begun (as announced in the team channel on Slack) and made good progress. A number of packages have been moved already and composer fetches them from GitHub by now. You might notice this because things get faster… 
The current progress can be seen on a Trello board at https://trello.com/b/IQYxJdlo/github-move and by following the activity in https://github.com/neos/
Once we are done, a proper announcement, documentation and some FAQ will be published.
