Renaming github repo from concrete5 to Concrete CMS

Developing with Concrete
5

We now have a generalized plan for this, but no specific time when you can expect that it be accomplished. I will post back when we actually have a specific time that we’re expecting to do this, because I imagine some of you might want to know, given the potential implications with Composer, etc…

Here’s our plan:

GitHub

The following organizations and projects must be renamed in GitHub:

  • concrete5 GitHub Organization (this part: https://github.com/concrete5/concrete5). Rename concrete5 to concrete (or, if that’s impossible, concretecms).
  • concrete5 GitHub Project (this part: https://github.com/concrete5/concrete5). Rename concrete5 to concrete (or, if that’s impossible, concretecms).
  • Any GitHub projects that also have concrete5 in their name within our organization (e.g. “concrete5/oauth2-concrete5” must be renamed to “concrete” instead of “concrete5”.

Packagist/Composer

The following packages need to be renamed in Packagist, which houses the PHP libraries we deliver to our sites and sites around the world. For each one of the following packages we need to do the following:

  • Update the name in composer.json on the master branch or whatever the default branch is
  • Resubmit the package to packagist using the new name
  • Mark the old package as “Abandoned” on packagist, and use the new name in the form so that people get pointed to it when they install with the old name.

This must be done for the following items:

  • concrete5/doctrine-xml
  • concrete5/dependency-patches
  • concrete5/core
  • concrete5/concrete5
  • concrete5/composer
  • concrete5/zend-queue
  • concrete5/oauth-user-data
  • concrete5/monolog-cascade
  • concrete5/phpass-compat
  • concrete5/cloudfront_proxy
  • concrete5/cloudflare_proxy
  • concrete5/sample_composer_package
  • concrete5/oauth2-concrete5
  • concrete5/nightcap
  • concrete5/migration_tool
  • concrete5/less.php
  • concrete5/incremental-filter-branch
  • concrete5/drop_box
  • concrete5/console
  • concrete5/concrete_cms_theme
  • concrete5/concrete5-api-client
  • concrete5/community_translation
  • concrete5/community_badges_client
  • concrete5/brand_central_connector
  • concrete5/brand_central
  • concrete5/fresh
  • concrete5/documentation_generator
  • concrete5/community_badges
  • concrete5/community_api_client

For all of these packages, rename concrete5 to concrete.

The Plan

This will require some fully dedicated time, likely with several Professional Services (and perhaps myself) people on a Google Meet. This should probably be done on a Monday or a Tuesday, so we have a couple days to catch problems or get community feedback.

In general, the plan is this:

Rename

  1. GitHub: Rename concrete5 organization to concrete or concretecms
  2. GitHub: Rename all concrete5 repositories to replace concrete5 with concrete or concretecms.
  3. Within packagist, following the rename procedure above for all repositories listed above.

Update Composer Install Package

The concrete5/composer package now needs to be updated to pull from the proper concrete/core location.

Test Composer create-project

Next, run composer clear-cache locally, and then run composer create-project and ensure that the proper dependencies are delivered. Ensure it works properly.

Test Legacy Composer Install

Manually create a project pointing to concrete5/core (not concrete/core) and ensure that composer.lock is generated properly and dependencies are delivered. This ensures their won’t be a hiccup in service to existing sites trying to get started out there.

Test Composer for Updates

Now it’s time for us to test packagist using our sites. Pick a site we can test for updating, and run the following on its develop branch.

  1. Open composer.json, update concrete5/core and any other concrete5 repositories with concrete/core and other concrete replacements.
  2. Run composer update locally and ensure that the new commits and properly brought in, and that things update sensibly. Have two members spot check composer.lock to make sure it makes sense.
  3. Push the new pull request up to Bitbucket and merge it into develop.
  4. Deploy develop to the stage of whatever site we’re testing and ensure deployment runs smoothly and the proper dependencies are brought in.

Once this is verified, we’ll know that we’re through the most difficult part.

Test Composer for Legacy

Now, let’s pick another site, and deploy its develop branch, without making any changes. This will ensure that we can continue to do deploys post-rename, without worrying about immediately having to update composer.json for hundreds of sites.

Questions

Have I covered all the bases? Missed anything? Please let me know in the comments inline or below. This should be the last major set of hurdles regarding the renaming – let’s ensure we’re not missing anything.

1 Like