home/about - roadmap - docs - mailing list - downloads/cvs - sourceforge project page - links

Generating Bug IDs

It's customary for database type programs to assign a unique ID number to individual data elements. Often times these numbers are simple auto-increment integers that start at 1 and work their way up to some very large number.

There are a number of reasons why a software project may want to use something other than auto-incremented numbers for it's unique IDs though. Three examples are:

  1. The auto increment number may give away some important information,
  2. Very little useful information is gained from the id number itself,
  3. Low numbers may give people the impression that you haven't been writting software very long (or maybe that you write bug free software, which would be bad because it wouldn't be true ;-)

WIth a simple bug/issue tracker such as pVigil, the first option is not of great concern. However the second option is. (the third option's importance is related to the size of your ego, so for many of us is the most important of the three)

I propose the following technique for generating the bug id numbers: (in the case below, + stands for text concatenation, not addition. i.e 1+1 = 11, not 1+1 = 2)

(year - 2000) + 2 digit month + 2 digit day + auto increment number that resets each day.

Therefor the 8th bug entered on May 4th, 2003 would be numbered 305048. If that's not clear, think of it like this: 2003-05-04-8 (although I think it should really be represented as an integer for database reasons).

Why is it better?

This improves on the auto increment system by a: telling you when the bug was reported, b: telling you how old the bug is, and c: by leading the world to think that your project has been around for quite some time to have squashed so many bugs. (or at least leaving the subject a mystery to those who know better but don't grasp the pattern)

Disadvantages is that in 17 years or so, a system will have to be developed to make sure bugs don't get dupplicate ids (hey, I squashed that bug years ago!). Also, busy days will add 1 or 2 digits to your bug id, so sorting bugs by id will need to be done as strings, not numbers. For example:

  305049 preceeds
 3050410 and both preceed
  305051 (even though numerically it's between the two)

* note: It just occurred to me that even string sorting won't get these guys in the right order. It would reverse the first two examples above. Fortunately, bugs also have dates so sorting by bugid will not be necessary.

Please, send feedback and give me any comments if you have them.

SourceForge Logo