Change namespace to "Ramsey"

[ramsey]

I've received a fair amount of feedback from people about the "Rhumsaa" namespace. Apparently, it causes confusion and makes it difficult to find my packages. On more than one occasion, I've received reports that I have misspelled my namespace (the assumption is that the vendor name of the namespace should be "Ramsey" and I have misspelled it as "Rhumsaa").

In the 3.0 release, I am considering changing the package name to "ramsey/uuid" and the root namespace to "Ramsey."

I'm opening this up for comments to get feedback from those who are using this package. I want to make the upgrade transition as smooth as possible, and I'd like to hear whether this will significantly impact people using "rhumsaa/uuid."

[xfoxawy]

using generic namespace is usually even more confusing for beginner to mid level developers ..
try to make it easier pal 💃

[simensen]

I don't believe that changing the package name on a major version bump will impact anybody currently using the old package name. There might be things to consider on the Packagist front, though? You probably won't want or need rhumsaa/uuid to pull updates from your repository. Not entirely sure how that will work. But from the perspective of a user, if I'm relying on rhumsaa/uuid I think everything will continue to work; they just won't receive new updates.

[fabre-thibaud]

I'm all for it. All I ever remember is that it starts with "rhum" (or is it rum ? one or two a's ?), but always end up looking it up on Packagist.

As for the BC break, well, it's a major bump, and honestly, I don't think it'll take anyone more than a global find/replace to fix it when upgrading a project. Pretty much every one of my projects with database entities uses Uuid, yet changing the namespace doesn't scare me the very least...

[weierophinney]

I like Rhumsaa as a vendor name for a few reasons.

• it's unique, and easy to search for (both on google and in github, but also when grepping through code).
• it gives you an easy possibility for moving the repo into an organization, because it's not identified with your username. (This latter is why I have used "Phly" as "my" namespace; I now have an organization separately, which allows me to add contributors and attribution.)

[kirkbushell]

Every time I've found your library, it's because I searched for UUID, not your actual name. Those who are looking for UUID implementations (nothing specific), will do the same. I see it as a moot point, to be frank.

[marijn]

I think it's not that much of an issue but if you think changing it will cause less support requests than by all means go for it. Do consider implications regarding Composer and please ensure that the old packages will be available under the known names and URLs. Nothing is as annoying as your builds suddenly failing because someone decided to rename their package or to move a package to a different URL.

[kirkbushell]

Even that's a minor issue though - easy fix :)

[ramsey]

I have decided to make this change. Thanks for the input and feedback.

[GrahamCampbell]

👍

[simensen]

@ramsey When are you planning on making this change?

[ramsey]

I'm hoping to get some time over the next week or so to make the change in the 3.0 branch. Soon after, I think I'll be ready to do a 3.0.0-alpha1 tag so that people can start testing it early with their stuff.

[simensen]

@ramsey Sounds good! I'm not in a rush but wondered if new projects I spin up should be using the new package name. :) Looked like nothing had changed yet and I wanted to make sure I hadn't missed something!

[marcj]

To sustain backwards-compatibility, you could use http://php.net/manual/de/function.class-alias.php.

[ramsey]

That's interesting. However, it might be best to do that in the 2.x series (2.9.0 maybe) as a way of deprecating Rhumsaa\Uuid and providing an upgrade path to Ramsey\Uuid. Then, in 3.0, remove the class alias.

Thoughts?

[fabre-thibaud]

Sounds decent. I'll throw my two cents by suggesting that you use class_alias to map to a subclass of Uuid that's able to trigger a deprecation warning. Otherwise, the change will most likely go unnoticed...

[simensen]

I'd just as soon you pull the bandaid off and make the switch. New namespace? New package name? It is a new package. In theory people will be able to install both packages still so if they need to install the old one because of a package dep, Composer will just do that.

[ramsey]

@aztech-dev I think what you're saying makes most sense to do in v3. It would not be easy to do in v2, without switching everything over to the new namespace. In order for it to work, I would use class_alias() to map Rhumsaa\Uuid to the subclass, which would look something like this:

class UuidDeprecated extends Uuid
{
    public static function uuid1()
    {
        trigger_error('This is deprecated. Use Ramsey\Uuid.', E_USER_DEPRECATED);
        return parent::uuid();
    }
}

While kind of cool and elegant, I'm not sure it's worth it, as @simensen has suggested.

[fabre-thibaud]

Yeah, I forgot about the new package when I suggested that. Don't know how Packagist will handle it though, considering the repo URL does not change.

[ramsey]

I'm already aware of how Packagist will deal with this. For example, with rhumsaa/vnderror, I changed the package name to ramsey/vnderror. In Packagist, I submitted a new package with the same GitHub URL, and it picked up the new package name from composer.json. It asked me to confirm that I wanted to create a new package, and I said yes.

Then, I marked rhumsaa/vnderror as abandoned (see here) and told it to recommend ramsey/vnderror as the new package. This seems to have worked fine, and since they're the same URL, both packages keep getting updated in Packagist (an unintended but okay side-effect).

When people run composer require and they have the abandoned package in their requirements, they'll see a message that looks like this:

[ramsey]

The only problem is the total download counts will be screwed up, but not a big deal.