We plan on changing our company name starting October 1st. All of our namespaces, projects etc use XYZ.ComponentName.
My question to you would be, on October 1st, what would you do? Change all the old components to ABC.ComponentName? Leave the old ones but any new development becomes ABC.ComponentName? Just stick with the old name?
Mixing and matching namespaces is often very troublesome and confusing from a maintenance standpoint. I would say that it really depends on the number of components you're dealing with and how many applications are dependent on them.
Perhaps it would make sense to map out the dependencies and get a feel for how much work you've got on your hands.
It Depends.
Some things to consider: If changing the namespace means moving files in CVS, then there is a penalty because you lose the history. If changing the namespace means manual work, you're going to miss places and cause bugs.
Also, do you have external users of the code/libraries? If they have to change their code because you've renamed the company, they will be annoyed.
I'd be inclined to leave the code the way it is. Namespaces are meaningless except to prevent collisions; at this point it's only marketing. But for new products I'd for sure use a new namesapce.
Where I used to work we had a few company-name or app-name changes and it was always problematic. One application was delayed by a couple weeks while they ironed out the bugs from a global namespace change at the last minute. Another application never adopted the new names and was always internally referred-to by the obsolete name, potentially confusing for new users. Imagine if everything in Java was still called 'Oak'.
That depends on if the components are stable, much used, if it doesn't to to much time to change, if there is time money and developers to change it...
Lots of if's.
I would probably just leave them as is. Changing them creates a nightmare in work, testing, and verification, and if somebody externally uses your library they also have to change their bindings to accommodate this change.
When Next was bought by Apple, they left the NS prefix as is, you can see this today with Apple's development frameworks. It won't kill you to leave them as is.
For new Namespaces you could change it to ABC but then you would break consistency, which could confuse people - especially new developers.
Just leave it as is and worry about other things :)
Also, watch out if you're doing any sort of dependency injection that uses reflection as that can then break.
Another problem is 3rd party code or other projects that use your project if there are any, as changing the namespace would break them.
The safest option is to leave the namespaces as they are.
Whichever choice you make, don't mix the two namespaces on new development. Be consistent. If you choose to stick with the old one, new development should use that too. If you move to a new one, move everything.
It may require some more analysis of the work involved with your particular scenario to decide if its worth it to switch or not.
Are you selling those components to 3rd parties? If not, then it's not worth the effort. If you are, then the namespace is part of your marketing and therefore should be changed.
It has been my experience in scenarios like this, that it is best to leave the namespace as it currently is. Any new libraries developed can use the new company name in the namespace.
As for the current pickle you find yourself in, I would ask for some $$ from the signage changing budget for fixing the code. If they don't give it to you, leave the old name be.
I think the proper answer is that you don't create namespaces with your company name in them in the first place. Pretty much everyone there knows who signs their paychecks; you alliviate no confusion by enshrining the name in code.
I had one coworker who discovered namespaces one day, and next thing I knew our entire software library has to be accessed through several layers of namespaces designating our company, division, and project. The thing is, we only really have the one project (although you could convince me of the benifit of that), the other divisions don't do software, and code we take from other companies doesn't follow his scheme. So really its just a lot of useless extra typing we have to do. Yes, we can do "using", but then there's no real benifit to the namespaces at all. Oh, and of course our division name changed a couple years later, when management decided "division" sounded to devisive, and we should now be called "teams". %-(
Namespaces are really best used whenever you have several classes which you would be tempted to name startimg with (or including somewhere) the same string. They aren't for mirroring your software development group's current management reporting structure.
why we need chaging the company name? it is benefit for us to change the company name??