blog
discuss
releases
documentation

Development Blog

Renumbering Firebug Releases?

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.

Thoughts?

jjb

12 Responses to “Renumbering Firebug Releases?”

  1. Dirkjan Ochtman Says:

    This sounds like a very good idea. I personally don’t use Firebug that often, but I do often run Firefox betas. This makes it kind of a hassle to find out what Firebug version best supports the current Firefox version I’m running. Your proposed versioning scheme would fix this.

    On the other hand, I feel that a very clear Firebug download page which shows a clean, large table of Firefox -> Firebug mappings would work just about as well.

  2. Anonymous Says:

    This seems like a fundamentally *bad* idea, for numerous reasons.

    * You won’t necessarily need to make changes for every new Firefox release, other than changing the compatibility. Thus, you may end up with Firebug 3.6 effectively identical to Firebug 3.5.

    * Actual enhancements to Firebug will end up only changing the minor release number, so Firebug 3.5.1 may have big enhancements over Firebug 3.5.

    * Firefox itself uses the minor version number. For instance, the stable 3.0 branch currently has Firefox 3.0.7. Firebug using the minor version number as well seems prone to confusion.

    * If you maintain Firebug compatibility with multiple versions of Firefox at once, such as 3.0 and 3.5, or 3.5 and 3.6, you will end up with multiple versions of Firebug, whereas now you can have a single version.

    * Version numbers already have fairly low information content, except as an increasing number. This change would remove what little information content they *do* have, such as the distinction between the magnitude of changes expressed by different parts of the version number.

    * The version number means little to people anyway. People will run the latest version from AMO, and they don’t really care what version number they get as long as Firefox keeps the extensions up to date.

  3. Da Scritch Says:

    Better have versions number like 3.5.0.1, to follow the normal version of Firefox (so it will be 3.5.0.1, 3.5.0.2, 3.5.1.1n…).
    Avantages :having rooom for important milestones of Firebug, instead of simple bugfixes.

    There is cases where Firefox doesn’t see new versions of itself, but can see new versions of its plugins (especially in Linux) and sometimes, users doesn’t see it.

  4. Ian M Says:

    Jump the versions numbers after significant releases.

  5. Álvaro G. Vicario Says:

    TortoiseSVN seems to follow a similar rule:
    - Tortoise 1.4 runs with Subversion 1.4
    - Tortoise 1.5 runs with Subversion 1.5

    So we eventually got this:
    - TortoiseSVN-1.5.0 & svn-1.5.0
    - TortoiseSVN-1.5.1 & svn-1.5.1
    - TortoiseSVN-1.5.2 & svn-1.5.1
    - [...]
    - TortoiseSVN-1.5.9 & svn-1.5.6

    Does it still look like a good idea?

    Historically, Firefox versioning scheme has always been… weird. They had the four digit system in v2 that lead to 2.0.0.18. Now they jump from 3.0 to 3.5 for the sake of marketing. Please don’t join such mess!

  6. Andreas Says:

    Who cares about version numbers anyway? They are so obsolete. People will only use the latest and gratest stable version no matter what it’s named.

  7. bwmaister Says:

    Since nobodies suggested it:

    Fx 3.5 gets Fb 3.5.0.1, and Fb 3.5.0.2, and Fb 3.5.0.3
    Fx 3.5.1 gets Fb 3.5.1.1 and Fb 3.5.1.2…

    basically, the fourth digit represents the Fb release since that version of Fx came out. (And yes, i think it should start with 1, although not strongly.)

    This has the added advantage of letting people know very easily if the version of Fb that is available when Fx releases is beta or not, without requiring a whole bunch of extra stuff:

    Fx 3.5 gets released, Fb 3.5.0.a is all that’s available, oh well. Of course, dear god, you could get into something like this:

    Fb 3.6.2.13a2pre… Don’t do that :)

  8. Dan Says:

    Question is: Is Firebug really as dependant on the Ff version as you suggest? If it is, then this makes sense. If it doesn’t then increasing the major version with each major release (one that breaks compatibility for example) should be fine as well.

  9. etlgfx Says:

    Renumbering firebug to follow Firefox’s PR numbering change seems strange, also using a point point revision for your own major version number seems backwards, maybe just flip it around:

    Firebug 1.4-3.5 (similar to what #17 said)

    That way should Firefox jump to 4.0 faster than you’re ready to call something Firebug 2.0 (usually signifying a significant upgrade / rewrite), your version numbers will still indicate your OWN products advancements not Firefox’s.

    examples:
    Firebug 1.4.1-3.0
    Firebug 1.9-3.5b4
    Firebug 2.0-3.5
    Firebug 2.0.1-4.0

    Just to give users an indication of the software dependency between the products, but not to tie your revisions to Firefox’s

  10. Dayson Says:

    Renumbering it isn’t really important. Don’t seem to have a problem with the present one. And it can check for updates automatically.

    What’s more important is to get the Firebug that works with Firefox 3.5 Beta 4 released.

  11. johnjbarton Says:

    Firebug 1.4 works with Firefox 3.5b4 and is available from http://getfirebug.com/releases. As far as I know, the remaining problems for 1.4 on FF 3.5 won’t be fixed until the next release of Firefox 3.5.

  12. Cliff Says:

    Alvaro, I don’t know what you mean about for the sake of marketing. They’ve explained that the new Firefox was just a victim of feature-creep, and since it became so much more different from 3.0 that it warranted a bigger version bump.

    I don’t care for Firebug to have any ties to the Firefox version really, anyone using it should be capable of figuring out what version works with what Fx without needing their hand held the whole way. I mean this is a tool for developers, hopefully we’re savvy enough for that at least.