[Packagist/Composer] Rename the package name from willdurand/expose-translation-bundle to willdurand/jstranslation-bundle

[willdurand]

Hi!

I'd like to rename the package name from willdurand/expose-translation-bundle to willdurand/jstranslation-bundle, but I am not sure to know the drawbacks. I know it is probably a "bad" idea, however I would like to know if it is feasible.

A few facts:

• 1.x reached End Of Life;
• 2.x is not stable yet, but I would like to make it stable with the new package name.

Requirements:

• For users who require willdurand/expose-translation-bundle in their projects, versions 1.2.0 and lower should still be available;
• Requiring willdurand/expose-translation-bundle with a version constraint asking for a version that is not 1.2.0 or below should fail;
• Requiring willdurand/jstranslation-bundle should work for all versions (as Packagist will detect previous tags I guess).

So, what would happen if:

1. I keep willdurand/expose-translation-bundle registered;
2. I register this repository with the new package name.

Thanks.

[ClementGautier]

Why not js-translation-bundle ?

[76200]

@ClementGautier 👍

[stof]

If you keep both, the update through the github hook will do funky stuff (it will probably only update only the old one and not the new one as MySQL will return the old one first in a query). The Packagist github hook does not behave well when you have several packages with the same name

[willdurand]

@ClementGautier @76200 to be consistent with friendsofsymfony/jsrouting-bundle.

[ClementGautier]

@willdurand it's not a really good excuse but ok.

[stof]

@willdurand I don't think it is a good excuse either. If you turn the camelCased named of the bundle into a dashed name, you get js-translation-bundle. An inconsistency in the FOS package does not need to be reflected here

[willdurand]

ping @Seldaek

[Seldaek]

I'd go with js-translation-bundle, if you need a consistency excuse you can pick nelmio/js-logger-bundle ;)

As for how to do it:

• rename the package in master branch
• re-tag or create a new tag for the 1.2 version + 1.1.1 or whichever are still relevant. those new tagged versions should have a "replace":{"willdurand/expose-translation-bundle":"1.2.*"} or equivalent in them, so that the new package replaces the old one and it can be deleted entirely
• add a replace for 2.0.* in the master branch
• submit the package again with the new name, and ask me to delete the old one

[willdurand]

Do I really have to force tags?

[Seldaek]

No you can create a 1.2.1 that replaces 1.2.* of the old one. and a 1.1.2 that replaces 1.1.*.

[willdurand]

done