Renaming of GitHub Repository

Discussion Topic

Our main working mode is using git.typo3.org for now, and Gerrit (review.typo3.org), but we mirror our repository in different places, e.g. on GitHub. Our mirror on GitHub is called “TYPO3.CMS” - this is for legacy reasons when we named packages with the namespace and the main package with a “.” when Flow and Neos was part of the TYPO3 namespace. This is how the naming happened in the first place (before it was “TYPO3v4” which was bad as well :slight_smile:).

I think it would be beneficial to rename the repository name. This takes away confusion and at the same time we can name it properly for newcomers to understand that this is our mono repository and not used for the actual composer packaging since we have our subtree split in place for 4+ years now.
The subtree split and the read-only repos have been proven stable, no change here for the time being.

Existing git.typo3.org infrastructure naming is kept for the time being, but that’s another story and not part of the discussion I want to kickstart here.

I’m open for suggestions about the naming (naming is hard, ya know), and I’m looking for more input. The current naming is “TYPO3/TYPO3.CMS” (Full URL GitHub - TYPO3/typo3: The TYPO3 Core - Enterprise Content Management System. Synchronized mirror of https://review.typo3.org/q/project:Packages/TYPO3.CMS)

A few ideas:

Impact

  • We need to adapt a few places where we reference the GitHub repository currently, but that shouldn’t be a lot of work
  • Since it’s not the main repository to work on, this shouldn’t affect a lot of people, especially not people in production.
  • When we rename the repo, GitHub will keep the old URL and put redirects in place, so this should be safe for everyone using it right now

Organizational

Topic Initiator: Benni Mack
Topic Mentor: Benni Mack

FYI: I’m fine with renaming our base composer package name (“typo3/cms”) to something else as well. And keeping git.typo3.org/TYPO3/TYPO3.CMS.git in line with our new naming too. Let’s get rid of “legacy reasons”.

Some quick data points:

  • Symfony follows a similar model (develop in a mono-repo, then split it out into individual repos for actual use). Their mono-repo is symfony/symfony. If we followed that pattern, that would be TYPO3/TYPO3.

  • Laminas is developed in stand-alone packages, primarily, and then bundled up into installable “kits.” Those are named laminas/laminas-mvc (don’t do that, FTLOG), mezzio/mezzio, and laminas-api-tools/api-tools-skeleton. So, not much guidance here.

  • Laravel both develops in and installs from a mono-repo, laravel/laravel.

  • Drupal develops in a mono-repo, and also has a “composer mode” that is recommended. That consists of a bunch of split packages, including drupal/recommended-project which is what you should install, and drupal/core which contains most of the original mono-repo.

  • Joomla appears to both develop in and deploy from joomla/joomla-cms.

  • October CMS (built on Laravel) develops in octobercms/october. Oddly it installs from october/october. (Probably a GitHub/Packagist mismatch.)

  • Magento is developed in magento/magento2, but installs in a weird and funky way because it’s semi-proprietary.

  • Wordpress is, well, Wordpress.

Conclusion: I don’t see a ton of standardization. The closest equivalents in workflow style seem to be Symfony and Drupal, which do somewhat opposite things.

My gut sense is that TYPO3/TYPO3 would be the least-surprising for people, as project/project is an extremely common pattern generally, even if larger projects sometimes get weird.

I think github.com/TYPO3/TYPO3 is most straight forward and looks best.

I’m against using cms as repo name.
Simple reason is that git clone github.com/TYPO3/cms would result in a cms/ folder, which makes little sense to me, all other options basically miss that same thing, you clone the repo and the folder name doesn’t contain TYPO3. Therefore I’m all in for TYPO3/TYPO3 :+1:

Further more I like the idea to fix our root composer.json name, as it is actually no longer used anywhere and that’s good to be reflected within the name.
I propose typo3/monorepo here, as it is nothing a user has to type and the name documents that.

Well, we use the github repo as submodule in production for some cases, but thanks to the renaming you outlined, github redirects will help out, so all fine, yes.

The more projects use it, the more it becomes “a thing ™”.
I’m with Larry and Benjamin on this one

+1 for github.com/TYPO3/TYPO3

+1 for github.com/TYPO3/TYPO3

+1 for github.com/TYPO3/TYPO3

Given the examples so far I also feel typo3/typo3 might be the best choice.
My first thought was that typo3/cms might be a good idea - but if you drop the vendor-name and end up with things like a folder “cms” from the checkout thats not ideal. Thus probably typo3/typo3 is the most natural things - “like others do it”.

We should then be prepared for the question what the name of the brand vs. product is. Like do we call the product TYPO3 itself (not CMS)? That’s probably what people out there would expect.

github.com TYPO3/TYPO3 sounds good. The composer name could IMHO reflect that it is not meant to be installed to avoid confusion (typo3/development-sources makes the most sense to me)

Maybe we could tackle
https://github.com/TYPO3/TYPO3.CMS.BaseDistribution/ (recommended starter package) and
https://github.com/TYPO3/CmsComposerInstallers/, too. Their repository URLs always felt a bit weird to me.

I would recommend
https://github.com/TYPO3/base-distribution/
https://github.com/TYPO3/composer-installers/

github.com/typo3/typo3

You mention stay away from legacy reasons. So go all lowercase. That all uppercase is weird in this context.

+1 for github.com/typo3/typo3 and keeping it lowercase: this is minimal, verbose (compared to typo3/cms) and extending the naming pattern to further projects in the namespace is straightforward by e.g. github.com/typo3/typo3-*.

On the contrary i also like the idea of the uniqueness of uppercased TYPO3 but would use it only in the namespace, not in the repository name, so +0.5 for github.com/TYPO3/typo3 and github.com/TYPO3/typo3-*.

Looking through all the “popular” projects (disregarding Frameworks and CMS solutions), I see a quote some /-names projects laying around (especially packages provided from what I’d call PHP ecosystem devs, like Giordi Boggiano, Ondrej Mirtes or Sebastian Bergmann):

  • monolog/monolog
  • composer/composer
  • phpstan/phpstan
  • phpunit/phpunit (although here only the package has this name and the project resides in Sebastian’s namespace)

So for me, it makes a lot of sense to go typo3/typo3 and for the sake of staying in line, I’d prefer the lowercase variant. Now for sticking out, I’d definitely go with all uppercase, but then again, usually people use UpperCamelCase for projects like FriendsOfTYPO3 or FriendsOfPHP.

Comparing the TYPO3 project with the PHP project (both have uppercase names) and looking at PHP’s repository cements the case for the lower case repository name.

What I would be definitely against is something like TYPO3/typo3, because I think this looks just silly :slight_smile:

+1 on github.com/TYPO3/TYPO3

In general I would have liked an information “this is a monorepo used for core develepoment, in projects you’re with the split packages”, but that is hard to reflect in the name and can be done via description or similar.

Cool idea, I also agree and think “TYPO3/TYPO3” is great, and “typo3/typo3” would be even better (but I am not sure of further implications in renaming the group itself too).

Just for completeness sake, Flow and Neos use these names for their mono-repos:

https://github.com/neos/neos-development-collection
https://github.com/neos/flow-development-collection

typo3/typo3 would work fine for me. The capitals are unnecessary, especially since they’re not allowed in the composer package name anyway. Then “the stuff you actually install” can be typo3/typo3-X or typo3/X, as we determine later.

+1 for github.com/TYPO3/TYPO3

This topic was automatically closed after 14 days. New replies are no longer allowed.