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:

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.


Comments

Popular posts from this blog

Issues changing the value of an element in an array in matlab -

php - MySQLi binding parameters in a prepared statement doesn't work unless inserted after "WHERE" -

vb.net - Alternative to the T-SQL AS keyword -