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.
2 Likes
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
2 Likes
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:
- The Demo Site e.g. configures Dimensions; and if you have a custom project where you want to develop Neos further, it would be extremely inconvenient to have the Demo Site active by accident.
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
2 Likes
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.
3 Likes
Not meaning to hijack this thread, it’s kinda related though 
Beard is now capable to fetch/manage patches from github commits and
pull-requests
2 Likes