Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We plan on changing our company name sometime soon. All of our namespaces, projects etc use XYZ.ComponentName.
My question to you would be should we change our namespaces? 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?
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’.