Without repeating good ideas from other answers, I have a problem in mind which wasn't addressed yet.

If you happen to do a fork, between an older version for backward compatibility, and a new version for an incompatible modernisation, you can't distinguish them via version numbers.

For example the Linux kernel was forked around the year 2000 into the old 2.4.x branch, which is probably still supported today and counts as 2.4.199, while the new version has been 2.6 for many, many years, and is 2.6.32 for older systems, but 3.2 for the newest kernels.

If you have documentation about your releases, you will double the information and tell the people, that version 20120109 arrived in 2012 at 01/09. Mh. But what, if there is a last-moment bug detection, and a release is delayed for a week, but the documentation, where the name is mentioned, is already ready, maybe printed, press information is out and so on. Now you have a discrepancy which is problematic, if version 20120109 arrived at 2012/01/13.

In SQL, the question whether IDs should carry semantic information has often been discussed, and the result is always: avoid it like hell! You're creating an unnecessary dependency. It can't be of benefit.

Ubuntu with its 04/10 scheme had its problem in 2006, when version 6.04 was delayed and became 6.06 . In year 3000 there will soon be the next problem! :)