The name of package of standart edition is symfony/framework-standard-edition https://packagist.org/packages/symfony/framework-standard-edition.

And there is a drawback: The api is not redirected => composer install does not work any more since the api is used by composer to download a package. (work only if you use --prefer-source

👎 package names are using different conventions than repository names, we should not make them equal imo.

(btw, renaming Validator to Validation is something that I like more, but I don't think that's going to happen...)

@lyrixx Are you sure? I thought it was.

yes, see also symfony/symfony-standard#558

Thanks. I wrote a mail to the GitHub support, let's see how this turns out.

@bschussek Yes, We got some issue during deploy because of this :(
You can see it with https://api.github.com/repos/sensio/SensioGeneratorBundle vs https://api.github.com/repos/sensiolabs/SensioGeneratorBundle

+1

Received a reply from the GitHub team:

Hi, Bernhard,

Thanks for the question. We want to bring this feature to the API, but we're trying to figure out the best way to do so. While browsers and the Git CLI can handle it, many API clients don't deal with 301's very well. We're trying to take that into account. Keep an eye on the API docs for updates.

Cheers,

---

Wynn Netherland
Developer, GitHub
@pengwynn

I propose to postpone this issue until the API redirects are fixed.

Don't know if this helps, but I told @fabpot about a similar issue on the sensio BuzzBundle last week (when sensio's repositories were renamed to "sensiolabs/*").

He fixes the issue really quickly (probably with a little tweak in packagist). So it's not a real 301 from the GitHub API, but it fixes the problem if you execute composer update to get the new API url in your composer.lock file.

@Swop it is still an issue with the API not redirecting. Updating packagist to use the new api url will not solve the issue for all projects locking the dependencies and having the old url in their lock file

@stof Yeah sure, as I say: "it's not a real 301 from the GitHub API".
But let's wait, to see if the GitHub team will manage that issue (BTW, thanks @bschussek for the post to the GitHub team).

Given that we are not 100% sure that everything will still work without problems after making the proposed changes, I think that it's safe to close this issue as won't fix.

I don't agree with closing issues just because we canot fix them now. It's still a valid issue that should be handled at some point.

The API is now redirected, so we might reconsider this issue.

This naming standard is already used for the newer packages, so big +1 to make everything consistent (if it doesn't cause problems, but these should be solved by the redirection).

Indeed, now that Github is doing the right thing, let's do that. I will try to make it happen this week.

Done