Development groups fall into one of two groups: they have boring numbers for releases, or they have weird project names for their releases. And sometimes the groups bounce back and forth between the two types.
Typically, what happens is a smallish group is used to following routine major.minor release numbering, but as the group grows and there may be two or more releases under development at the same time, the numbering scheme gets a bit strange. For example, the team working on release 4.2 may be supposed to push to production before release 4.3, but if there's a delay in the first team, either release numbers have to be juggled or delays get imposed for no reason. And, as the groups grow, there's incentive to be a little "crazy" in the development process and drop the routine numbering and move to the project names that best amuse the group.
I've seen it happen a half dozen times. In the last case, we had eight project groups maintaining four products, each doing leapfrog releases with routine numbering. To add some spice to the process, as well as to prevent the numbering schemes from messing up, the team leads asked if they could start using code names for releases, assigning the release numbers only when the code was frozen. Most developers read about Microsoft and other large companies running code-word projects, and it does add a little bit of excitement to the process, so why not let them go ahead? I OK in almost every case, and let the teams come up with names.
Most teams like to have names for releases that are tied to particular things. For example, one team chose cities, so their releases were named after major cities. Another chose mountains in the Rockies. Another team chose legendary monsters. And so on. This is all well and good for the teams, who know what's next ("We're working on 'Paris' now, 'London' just got released, and 'Rome' is next up") but for those outside the groups it can be a little confusing. I remember one case where I was trying to explain to the executive team that a particular feature would be appearing in the 'Chupacabra' release, which was due a month after we got 'Boo Hag' out the door. Not only does that not convey any real information to the executive team, but I had to explain what each term meant!
So, while I fully support project names, all as part of the fun of the development groups, we tend to keep those names internal to R&D and assign working release numbers for those outside the teams. It makes it a lot easier for others to understand, and I don't have to run to the Dictionary of Legendary Monsters every time a new release is announced!