While I still don’t get why Firefox is renumbering its next release to 3.5, the discussion did make me think about the Firebug version numbering. Our current user release is 1.3.3 which targets Firefox 3.0.4+. Our next release is 1.4 and we will be targeting Firefox 3.5. These Firebug major release numbers have very little information content. Firebug 1.n is just the n-th release since 1.0.
So what if we jump 1.4 up to 3.5 and then track the Firefox release nmber. That is, the Firebug major release number would just be the target Firefox release number: Firebug 3.5 is for Firefox 3.5; Firebug 3.6 is for Firefox 3.6.
If we have a major Firebug release more often than Firefox (as we plan to do), we’ll jump up the third number. So we might go from 3.5.1, 3.5.2, 3.5.3, then 3.5.10, 3.5.11, 3.5.12, or 3.5.50, 3.5.51, 3.5.52, and so on. These numbers would be for the addons.mozilla.org version; the getfirebug version would start with 3.5.0a1, then when we freeze the features we’d start 3.5.0b1 until we are ready for amo at 3.5.0.
The cost is a one time renumbering and explanation, plus on-going cost of tracking Firefox numbers. What I most dislike about renumbering is the feeling that we promised 1.4 and 1.5, but not we are not delivering, exactly. We want to provide a steady resource for users and extension developers, something they feel they can count on. But the advantage of having our major release numbers match Firefox seems more valuable.