So we’ve left the repo in github named concrete5 because we’re worried about what trickle down issues will emerge if we just rename it.
Can we discuss that here? We need to plan this out and make it happen.
IMO, you just set the date in 2-3 month ahead of the time so that we can prepare, and go.
I’d suggest to rename the repository, and avoid creating a new clone of it.
Why? GitHub is very smart: when you rename a repository, every web and git request that use the old URL will be automatically redirected to the new one.
For example, I renamed https://github.com/mlocati/login_destination to https://github.com/concrete5-community/login_destination (see How to move a GitHub repository to the concrete5-community organization - YouTube to see how I did it).
If you visit the old URL with the browser, you’ll be automatically redirected to the new one.
And even git clone https://github.com/mlocati/login_destination.git still works.
1 Like
Oh, I just came up.
We also have to think about what to do with composer!
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
- GitHub: Rename concrete5 organization to concrete or concretecms
- GitHub: Rename all concrete5 repositories to replace concrete5 with concrete or concretecms.
- 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.
- Open composer.json, update concrete5/core and any other concrete5 repositories with concrete/core and other concrete replacements.
- 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.
- Push the new pull request up to Bitbucket and merge it into develop.
- 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
We have added this to the calendar.
On May 17, at 9AM PST we will start the process of renaming these repositories and organizations. We will also talk about this in our next town hall (May 10) in case you have additional questions that haven’t been answered by this thread.
I apologize for being late to this discussion. Have you considered changing to a domain or sub-domain URL? Who knows, maybe Github (owned by Microsoft) will be the next thing to change, you’ll want to move your repository elsewhere, and have to do this all over again.
Perhaps you could point the new domain/subdomain URL to the current repository and and phase in the change over a couple years.
@fixt.org GitHub allows you to use a custom domain only for GitHub Pages.
GitHub Pages is a service offered by GitHub that allows you to publish something in HTML format.
Consider for example this repository: https://github.com/mlocati/timezone-converter
It’s docs folder is published (thanks to GitHub Pages) as https://mlocati.github.io/timezone-converter
What you can do is to use a custom domain for https://mlocati.github.io, not for https://github.com/mlocati
Thank you for taking the time to reply. I figured pool of expertise working on ConcreteCMS wouldn’t have overlooked something so basic, but I had to ask.
You’d think (or at least I did) GitHub would design a better way to manage a repository name transition via DNS or cloning to the new repository. There must be many other projects facing the same name change dilemma.
As I wrote above, GitHub should already automatically perform web redirects and handle git requests flawlessly when renaming repositories.
Good point, carefully read the entire forum thread before writing.
I can certainly sympathize with Portland Lab’s concern, there’s a lot of work and history on the line. I’m sure they’ll rest easier after GetHub makes that flawless transition happen.
1 Like
Yep, I agree (but I still haven’t understood the reason of all of this mess… what was wrong with the concrete5 name?)
1 Like
We liked the name, but so many people couldn’t understand that the version numbers were 8.x and 9.x rather than 5.8.x and 5.9.x (along with the ensuing amount of changes) that it just made it very difficult to explain to people that there were big changes happening in the Concrete ecosystem.
Just an update on this – we have started this process as of 9am PST this morning. We’re getting held up on the organization rename since we already owned the concretecms organization and deleted it to make space for this rename (and now GitHub is holding onto that organization name for the 90 day period.) We’re working with GitHub to move this forward, but it may be a slow process.
2 Likes
Haven’t seen the changes on packagist, I assume you are halting because of GitHub?
Correct. Unfortunately at the time we may have to abort due to GitHub policy
1 Like
Well, the github repos have been renamed, haven’t they?
Yes, as of now the concrete5 organization, the concrete5 repositories and all the composer projects have been renamed to use concretecms instead.
The old concrete5 Composer projects are still there - many of them have been marked as abandoned (and the rest will be soon). They’ll still continue to exist of course, but you should migrate your development tools to use the new concretecms URLs on GitHub.
I suspect we’ll see some tweaks that need to be made in the coming days, but hopefully the most difficult parts of the transition are behind us.
2 Likes