Renaming URHO3D to U3D?

[SirNate0]

Since the repository was renamed, do we want to shorten the namespace, macro, and folder names as well?

I vote yes for at least the macro names, I don't have much of an opinion on the rest. Though I think we should keep Urho3D is in the copyright statements in the code/license.

[klaussilveira]

Yes, I have a "rebranding" PR incoming. This is a major BC break, but I think it is important to differentiate the projects, as well as from 1.x to 2.x.

[eugeneko]

This is a major BC break, but I think it is important to differentiate the projects, as well as from 1.x to 2.x.

Are you certain it is worth it?
People who currently use Urho 1.8- may not want to switch to your project for this breakage alone.
When doing rbfx, we tried to keep as much continuity as possible to help people migrate.
And rbfx intended to be just a personal fork for fun, while U3D aims to be the descendant of Urho3D (afaik).

I have no say in the direction/development of U3D, but I still want to make this statement here.
I am afraid this rebranding may inflict more harm than good.
Benefits are all ephemerical, but the harm is very real: the time wasted on patching code.

[klaussilveira]

I do share that concern. Not renaming can lead to confusion, inconsistency and a whole breed of "it works in Urho 1.9/1.10 but not in U3D". At the same time, renaming causes a big break, requiring cumbersome search and replace, and will break compatibility with old tutorials/documentation.

Everyone has a say, so I would love to see more discussion around this, specially once a PR is open, so the community can choose the path forward.

[SirNate0]

I'm not certain, but I think it may be possible to do the remaining without breaking backwards compatibility (significantly) by having a compatible header, say Urho3D.h, which still defines the Urho3D namespace with a using namespace U3D; inside, as well as defining the old macros and defined to wrap the new ones.

[klaussilveira]

I've created a new milestone, 1.9, containing all of the important tasks that won't have any big BC break. For 2.0, we can discuss potential BC breaks and how to mitigate them.

@SirNate0 I really like the alias header idea.