The "normal" way of doing things is:
- Whoever finds out the flaw contacts the vendor.
- Vendor makes the patch, and publishes it, pushing it to customers with a vague but scary description ("fixes a flaw allowing for remote code execution").
- A few weeks later, details are published. If all went well, the initial discoverer makes the publication, in full agreement with the vendor, so that due credits are attributed; and the vendor adds a link to the publication details in his own documentation.
For instance, this is what happened with the SSL-related flaw dubbed "CRIME": browser vendors were warned several weeks in advance, and pushed patches. Occasionally, the vague description can be enough for some people to guess what is happening a few days before actual publication. The dance is a matter of delicacy, especially with opensource software, because patch source code is often quite revealing about the exact nature of the issue.
One psychological side of the issue is that vulnerability hunters are a tough crowd who may react, sometimes, in somewhat heated emotional ways, if they feel that vendors don't react appropriately or fast enough. Software vendors would usually prefer to keep flaws secret, but if they have to accept publication, then, at least, they really prefer to have some advance warning. The "due credits for prior warning" barter is an arrangement which has a high probability of convincing most bug-hunters not to push the exploit right away on public channels, so software vendors will support this "normal way".
Ultimately, when the dust has settled, all details should be published, because full disclosure is a great foundation for trust.