Hacker News new | ask | show | jobs
by keypusher 4788 days ago
You are assuming a monotonically increasing version number. What happens when you need to go back to the old "version" and push out an update? For instance, you shipped 3.0 a few months back but most of your users are still on 2.7. Uh, there's a bug on 2.7, you need to push out a fix. If you are doing versions by date, then there is no easy way to distinguish parallel development.
1 comments

Just to play devils advocate, you could use both versioning schemes. For example, 13.01.24 could indicate it was the 24th revision of the 13.01 release (as opposed to being released on the 24th of the month).
I like this idea the best, but I think revision numbers are conventionally prefixed with a dash;

    13.01-24
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pac...

(i can never quite distinguish between revisions and releases... when is each used?)

Yeah, that would be better.

In this context a revision is just a bug fix release, the same as a "point release" or "minor release" or "patch version." I'm sure there are terms I'm forgetting. A micro-version increment, where the system is ${major}.${minor}.${micro} (in what the kids call "semantic versioning," but what used to just be called "not versioning like an idiot.")

Yeah, that wouldn't be the slightest bit confusing.