What do I need to learn to decide on rename/recompile source package names because of company rebranding?

Question

My company is currently at a rebranding process and the brand names have been used in the sources' package names but these names are only visible to developers who maintain this code so nobody from project management is really interested in changing them considering also that it would imply the recompiling of several old components.

What factors do I need to consider when deciding on a change like that?

I don't know if I should worry about legal issues or not and if so, how to address this with project management.

---

_{More background details. I have all the sources and dependencies but since the company rebranding, other development areas have adopted some of the code that needs package name-changing so I cannot take the decision only by myself so I don't make everyone else's code to crash with my core components and I cannot change other areas' code without the permission of those areas' users so yes, my concern is more political than technical. I am going try to coordinate the involved it areas to make the change anyway, since it seems to be the best approach.
 
Unfortunatelly in my company there's no continuous integration build server so we build our code manually on demand and to get something to production I have to justify the change (even just the package name changing) to QA with an user requirement and some other bureaucratic documentation so that's why I was hesitating the change in first place.}

Answer 1

This is usually a political/marketing question as much as technical. I have been involved in mergers where changing all references to the old name was mandated

Assuming it is just a technical question, are you missing buildable source for any of the components or are there similar significant technical risks? Will making the change break backwards compatibility when backwards compatibility is important? If the answer to either of these questions is "yes", clearly avoid the change.

Otherwise, I would recommend making the change. Changing it is only going to get harder as more development is done and, otherwise, you will need to explain it to every new developer on the project.

Answer 2

While there's no immediate need, eventually as new code gets the new name it's going to become a pain remembering whether something uses the old or the new name. It's a simple fix, so you may as well get it over with. The main reason not to would be if your code was widely shared outside your company. If you control all the source code it's only a minor inconvenience.

As far as having to recompile old components, I'm not quite sure I follow you there. We recompile all our code a few times per day, and consider that to not be often enough. If you're not using a continuous integration build server, it's well worth the investment.

Answer 3

How many source files are you talking about? If lots then it starts to become a problem.

But then again, I presume the Grown Ups factored the costs involved when considering the rebranding? Or did they just consider the reprint of letter heads and business cards?

My view (which seems to match the previous commentators) would be to JFDI... perhaps to keep QA happy, raise a standalone change request (or whatever the company parlance is) to do it - in theory this should be a "no executable impact" change - ie the new output should be the same as the old one.

Perhaps also, you should increment the major version, to start as a clean slate?