versioning - Calendar aligned version numbers for an unpaid application -

the internal application team works on on version 10.y.z.build_number.

during discussion if next release significant enough 10.y+1.z.build_number or should 10.y.z+1.build_number suggested keep simple , align version numbers calendar.

for example next release 13.8.1.build_number stands 1st release august 2013. september 1 13.9.1.build_number.

the idea has been discarded now.

for paid application can imagine having 1st number useful distinguish between releases free upgrades , major releases require paid update. x+1.y.z paid , x.y+1.z free.

after quick search found jeff attwood's what's in version number, anyway?.

however unpaid internal application cannot think of weak points calendar-aligned version numbers , beauty of simplicity speaks me. 1 of comments on jeff atwood's post says: microsoft office 2003 far more meaningful name microsoft office 11.

the question: vision clouded enthusiasm , there known issues calendar-aligned version numbers?

for internal application, information version needs convey revision or commit of sources said app built.

since have access vcs managing app sources, version can bug reporting like: "found in revision xxx".
far more valuable date-based tag, can subject interpretation in order find exact version of sources exhibiting bug need reporting.

you can combine version policy want, tags: git, instance, can generate unique version number based on sha1 + tag. see:

• "deriving application build version git describe - how relatively straightforward string?"
• "simulating global revision number git"

but idea remains: date metadata managed vcs or build scheduler jenkins/hudson/teamcity... doesn't have in public version number of app.

what need in version number info allowing exact sources app built.