Rename static-php-cli to StaticPHP
What does this PR do?
Prepare for future brand promotion :/
I have reservations about renaming and moving the repository, as GitHub will automatically redirect to the new repository, so it may not be difficult. But I think it's not too late to do it after version 3.0.
Checklist before merging
If your PR involves the changes mentioned below and completed the action, please tick the corresponding option. If a modification is not involved, please skip it directly.
- If you modified
*.phpor*.json, run them locally to ensure your changes are valid:- [ ]
composer cs-fix - [ ]
composer analyse - [ ]
composer test - [ ]
bin/spc dev:sort-config
- [ ]
- If it's an extension or dependency update, please ensure the following:
- [ ] Add your test combination to
src/globals/test-extensions.php. - [ ] If adding new or fixing bugs, add commit message containing
extension testortest extensionsto trigger full test suite.
- [ ] Add your test combination to
static-php instead of StaticPHP? Not sure, but StaticPHP looks unexpected.
StaticPHP appears to be more SEO-friendly. Using it as the brand's display name (while the internal names and IDs are still static-php and static-php-cli) is, I guess, a relatively safe solution.
I think SEO friendly is not a thing we need to care about. My concern is that we already have static-php.dev, my packages link to it and people already know the project as static-php(-cli).
Haha, actually I personally prefer calling it spc and static-php, but static-php with a hyphen feels more like a static word for PHP than a brand name. Static PHP with a space doesn't feel as good as static-php, but it's not elegant enough. I'm intentionally referencing the syntax of FrankenPHP, CakePHP, and NativePHP etc, so I'm thinking of doing it this way (brand name is Camel Case and internal is lowercase).
Of course, given that our project is already well-known, I think keeping static and php is fine, ultimately. The name people call it will depend on the repository name and the document title.
That's a fair point. Is staticphp.dev for the grabs?
Now I've owned static-php.dev and staticphp.sh (not used but no idea how to use and I don't plan to renew my subscription for now), staticphp.dev is available for now. I could have it and redirect to static-php.dev or vice versa.
That's a fair point. Is staticphp.dev for the grabs?
Now I've owned
static-php.devandstaticphp.sh(not used but no idea how to use and I don't plan to renew my subscription for now),staticphp.devis available for now. I could have it and redirect to static-php.dev or vice versa.
When we're switching to StaticPHP it should probably be static-php.dev -> staticphp.dev.
Since we need more time to finish v3 version of SPC, I think we could update it and move the repo when we published the first new beta version, and announce it soon. Mainly because we need to reorganize the documents and README.
Agreed, let's keep the branch open, though.