Firefox version numbering

1 view
Skip to first unread message

Ben Williams

unread,
Jun 19, 2008, 4:03:03 AM6/19/08
to
I'd like to have a discussion about Firefox release numbers for point
releases.

Back in the day of Firefox 2, we reached (I think) 2.0.0.14 before FF3
was released (sidetrack: can't believe how much awesome FF3 has got on
OSX. Completely in love, again. Awesomebar FTW).

Now, I completely understand wanting to release major updates as major
version numbers - and if the improvements in FF3 don't qualify for a
major version number update, then nothing does.

What I really dislike is the practice of numbering point releases in
the minor-minor-minor numbers. 2.0.0.14! All I can see that it
achieves is making people sound like ultra detail-obsessed nerds when
they talk to their non-tech friends: "Have you got the latest
Firefox?" "Yeah, I've got version 2." "is that 2 point oh point oh
point fourteen, or two point oh point oh point 13?" "...?"

OK, contrived example, but that's the point I want to make - why
aren't these updates released as, say, 2.0.1 at least, or (even
better) versions like 2.1 or 2.2? I'm not sure if it's maybe the
release engineers or developers (not sure who decides on version
numbers) trying to minimise the "major-ness" of the update's
appearance? ("Oh, it can't be that much of a change, it's only
2.0.0.13 to 2.0.0.14")?

I'm not trying to be flamebait here, just trying to ignite some
conversation about something that has irritated me for a while. Just
so I'm not criticising without anything useful said, how can it be
improved?

There are probably a couple of options. The most extreme would be to
release everything in the first minor decimal place; e.g. 3.0.0.1
would actually be 3.1, 3.0.0.5 would be 3.5, etc. The biggest problem
with this is what would have happened to FF2, which is, what happens
when there are more than 9 point releases?

I think a better scheme would be for minor bugfix releases to go in
the third decimal place - so 3.0.0.1 would be 3.0.1 - and security or
other important fixes to go in the first minor version (say 3.2). So
say if this happened:
Release: v3.0. Celebrate!
minor bugs fixed, new release: v3.0.1
more minor bugs fixed, new release: v3.0.2
security issue fixed, new release: v3.1
non-security bugs fixed, new release: v3.1.1
non-security bugs fixed, and much better history viewer integrated:
v3.2
...and so on, until Major New Feature release: 4.0. Celebrate again!

I reckon that allows enough flexibility to cope with 14 point
releases, avoids silly long version strings, and better indicates the
relative "importance" of a point release.

What do you think?

- Ben

Thomas Stache

unread,
Jun 19, 2008, 5:33:54 AM6/19/08
to
Your preaching to the choir ;-)
Firefox 3 will use the 3.0.1 scheme.

Philip Chee

unread,
Jun 19, 2008, 6:19:01 AM6/19/08
to
On Thu, 19 Jun 2008 01:03:03 -0700 (PDT), Ben Williams wrote:

> minor bugs fixed, new release: v3.0.1
> more minor bugs fixed, new release: v3.0.2
> security issue fixed, new release: v3.1
> non-security bugs fixed, new release: v3.1.1
> non-security bugs fixed, and much better history viewer integrated:
> v3.2
> ...and so on, until Major New Feature release: 4.0. Celebrate again!

Dear Rip van Wrinkle,

The next point release will be 3.0.1 and the next feature release will
be 3.1 due out sometime in October.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]If I save time, when do I get it back ?
* TagZilla 0.066.6

Mike Beltzner

unread,
Jun 19, 2008, 8:26:43 AM6/19/08
to Philip Chee, dev-apps...@lists.mozilla.org
----- "Philip Chee" <phili...@gmail.com> wrote:

> On Thu, 19 Jun 2008 01:03:03 -0700 (PDT), Ben Williams wrote:
>
> > minor bugs fixed, new release: v3.0.1
> > more minor bugs fixed, new release: v3.0.2
> > security issue fixed, new release: v3.1
> > non-security bugs fixed, new release: v3.1.1
> > non-security bugs fixed, and much better history viewer integrated:
> > v3.2
> > ...and so on, until Major New Feature release: 4.0. Celebrate
> again!
>
> Dear Rip van Wrinkle,
>
> The next point release will be 3.0.1 and the next feature release
> will
> be 3.1 due out sometime in October.

It won't follow the exactly numbering scheme you propose, Ben, but as said earlier, stability releases will be the third digit (3.0.x). If we make changes or additions to the functionality of the rendering engine or product, you'll see that as 3.y (and then security updates to that will be 3.y.x)

FWIW, though, I'd like to step away from version numbers altogether, and go to something like "Firefox, December 2008"

cheers,
mike

Thomas Stache

unread,
Jun 19, 2008, 9:12:06 AM6/19/08
to
Mike Beltzner wrote:
> FWIW, though, I'd like to step away from version numbers altogether, and go to something like "Firefox, December 2008"

Interesting idea, from a marketing point of view. But for extension
compatibility and update checks the numeric scheme will likely keep its
importance.

Mike Beltzner

unread,
Jun 19, 2008, 9:28:31 AM6/19/08
to thomas...@gmx.net, dev-apps...@lists.mozilla.org
Yes, of course we'd keep this number for compatibility reasons - I meant in
terms of user facing labeling.
And it's not a marketing thing. It's a "don't force users to understand our
implementation model" thing. :)

cheers,
mike

_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox

Ben Williams

unread,
Jun 19, 2008, 10:50:27 AM6/19/08
to
On Jun 19, 9:26 pm, Mike Beltzner <beltz...@mozilla.com> wrote:
> It won't follow the exactly numbering scheme you propose, Ben, but as said earlier, stability releases will be the third digit (3.0.x). If we make changes or additions to the functionality of the rendering engine or product, you'll see that as 3.y (and then security updates to that will be 3.y.x)

Sensational, that's great news. I hadn't heard anything about this
scheme on the various blogs etc, so I'm happy to have brought up
something that's already been improved :)

> FWIW, though, I'd like to step away from version numbers altogether, and go to something like "Firefox, December 2008"

That's a really interesting idea - kinda like Ubuntu with its
8.04/8.10 for April 2008/October 2008 type releases. And for update
checks - it's pretty easy to translate a date to an absolute number,
so I don't see that being a problem. There *is* something nice about a
Big Integer Point Oh release though.

- Ben

Peter Weilbacher

unread,
Jun 19, 2008, 11:01:33 AM6/19/08
to
On 19.06.2008 14:26, Mike Beltzner wrote:
> FWIW, though, I'd like to step away from version numbers altogether, and
> go to something like "Firefox, December 2008"

How do you differentiate updates from different branches that are released
in the same month, like e.g. FF 3.0 and FF 2.0.0.15 now?
Might be cool for marketing, but already for support I would hate that, let
alone real bug reports and development, even if the UA string still contains
a proper version number.

Peter.

Philip Chee

unread,
Jun 19, 2008, 11:38:16 AM6/19/08
to

I hope this doesn't include Ubuntu style alliterative animals e.g.
"Bouncy Bobono Firefox"

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[ ]What's shorter then a weekend? A Vacation.
* TagZilla 0.066.6

Boris Zbarsky

unread,
Jun 19, 2008, 11:57:38 AM6/19/08
to
Mike Beltzner wrote:
> FWIW, though, I'd like to step away from version numbers altogether, and go
> to something like "Firefox, December 2008"

That's an interesting idea, if we can sort out a way to tell apart "Firefox,
June 17 2008" (Firefox 3.0.0) and, say, "Firefox, June 30 2008" (Firefox 2.0.0.15).

That is, just date doesn't work if we have multiple parallel release branches.
We need a branch identifier as well.

Note that last I checked we weren't going to drop 3.0.x support when 3.1 (or
whatever it's called) comes out either...

-Boris

Mike Beltzner

unread,
Jun 19, 2008, 12:02:32 PM6/19/08
to Peter Weilbacher, dev-apps...@lists.mozilla.org

I'd be fine with:

Firefox 2, Last Updated June 2008
Firefox 3, Last Updated June 2008

Again, this is *not* marketing, and I am somewhat distressed to hear
people think of it that way. Users don't grok version numbers nor
their schemes, especially for security and stability updates. What
they want to know is "do I have the latest version?".

Yes, for support, the exact version number is needed. I am suggesting
that we put that onus on our support team rather than our users. :)

cheers,
mike

Mike Beltzner

unread,
Jun 19, 2008, 12:03:35 PM6/19/08
to Boris Zbarsky, dev-apps...@lists.mozilla.org
Yup, that'd work. In many cases, the only time we'd need the human-
readable naming would be in the update dialog and on our webpages as
well. The actual version number could still be included, as Boris
suggests, in the About dialog box.

cheers,
mike

John J. Barton

unread,
Jun 19, 2008, 12:31:37 PM6/19/08
to
Mike Beltzner wrote:
> On 19-Jun-08, at 11:01 AM, Peter Weilbacher wrote:
>
>> On 19.06.2008 14:26, Mike Beltzner wrote:
>>> FWIW, though, I'd like to step away from version numbers altogether, and
>>> go to something like "Firefox, December 2008"
>>
>> How do you differentiate updates from different branches that are
>> released
>> in the same month, like e.g. FF 3.0 and FF 2.0.0.15 now?
>> Might be cool for marketing, but already for support I would hate
>> that, let
>> alone real bug reports and development, even if the UA string still
>> contains
>> a proper version number.
>
> I'd be fine with:
>
> Firefox 2, Last Updated June 2008
> Firefox 3, Last Updated June 2008
>
> Again, this is *not* marketing, and I am somewhat distressed to hear
> people think of it that way. Users don't grok version numbers nor their
> schemes, especially for security and stability updates. What they want
> to know is "do I have the latest version?".

And how does this scheme help? I say not at all, because the problem
for users and versions isn't the number/naming scheme it is the obscure
way the version is revealed to them. Help->About->Some funky info. If
the version info was directly in the help menu or in the title bar fewer
problems.

Furthermore this scheme raises lots of issues. June 16? June 17 GMT?

>
> Yes, for support, the exact version number is needed. I am suggesting
> that we put that onus on our support team rather than our users. :)

Seems like this scheme would put the onus on extension developers as
well. We don't have a support team....

XtC4UaLL

unread,
Jun 22, 2008, 6:15:07 AM6/22/08
to
On 19 Jun., 15:28, "Mike Beltzner" <beltz...@mozilla.com> wrote:
> And it's not a marketing thing. It's a "don't force users to understand our
> implementation model" thing. :)

it's a good idea, but i guess it's too late for this kind of change.
users already adopted the cuttent versioning system for the past 9 (?)
years [Mozilla Suite + Fx + TB + Sunbird + ...].
any change now would only spread confusion (and this is not only
because several moz.org products will be named differently then cause
nobody thought of broken consistency amongst them ...).

Gervase Markham

unread,
Jun 23, 2008, 5:33:04 AM6/23/08
to
Boris Zbarsky wrote:
> Mike Beltzner wrote:
>> FWIW, though, I'd like to step away from version numbers altogether,
>> and go
>> to something like "Firefox, December 2008"
>
> That's an interesting idea, if we can sort out a way to tell apart
> "Firefox, June 17 2008" (Firefox 3.0.0) and, say, "Firefox, June 30
> 2008" (Firefox 2.0.0.15).
>
> That is, just date doesn't work if we have multiple parallel release
> branches. We need a branch identifier as well.

Only if we make releases on two branches on the same day. And I'm not
sure the release team would like that suggestion :-)

(As long as the full version number is available somewhere for support.)

Gerv

Justin Dolske

unread,
Jun 23, 2008, 8:40:14 PM6/23/08
to
Mike Beltzner wrote:

> FWIW, though, I'd like to step away from version numbers altogether, and go to something like "Firefox, December 2008"

I'd want to keep the major version number -- using it simply as a
sequential identifier -- and use the date to replace the other version
number mumbo-jumbo. I think there's value in having something sequential
to refer to [did you like Star Trek 1989 better than Star Trek 1991?],
and it avoids ambiguity with the problem bz mentions [Is Firefox (2)
July better than Firefox (3) June?].

I'll also note that dates can be a annoying for those on the
technical/engineering side. This was a headache for me at Sun --
internally we worked on things like "Solaris 9 Update 3", but externally
the releases were named like "Solaris 9 5/02" (May 2002). Mapping dates
to/from versions was a hassle, and it wasn't always clear what the most
recent version really was. (The latter probably isn't as much of a
problem for FF, since we'd have faster release cycles).

Justin

Tony Mechelynck

unread,
Jun 23, 2008, 9:28:55 PM6/23/08
to

For bug & regression tracking etc., I believe that it would be useful to
have something like (at least) "Minefield 3.1a1pre (Linux i686 en-US)
2008062302" remain accessible (in any order). Whether "Gecko" and
"1.9.1a1pre" might be useful too I'm less sure, but I won't rush to say
they aren't. All in all, I think a _very good_ cause would need to be
built before we move away from the current UA style, which, for the same
build, is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre)
Gecko/2008062302 Minefield/3.1a1pre".


Best regards,
Tony.
--
"I'd love to go out with you, but I never go out on days that end in
Y."

Justin Dolske

unread,
Jun 24, 2008, 11:58:05 AM6/24/08
to
Tony Mechelynck wrote:

> For bug & regression tracking etc., I believe that it would be useful to
> have something like (at least) "Minefield 3.1a1pre (Linux i686 en-US)
> 2008062302" remain accessible (in any order).

That's not what this thread is about. Such version numbering would of
course be available to those who really want the gory details.

Justin

Boris Zbarsky

unread,
Jun 25, 2008, 12:49:50 AM6/25/08
to
Gervase Markham wrote:
>> That is, just date doesn't work if we have multiple parallel release
>> branches. We need a branch identifier as well.
>
> Only if we make releases on two branches on the same day.

"work" means "effectively communicates which is newer", not just
"uniquely identifies the release".

-Boris

Mike Shaver

unread,
Jun 25, 2008, 6:47:21 AM6/25/08
to Boris Zbarsky, dev-apps...@lists.mozilla.org

2.0.0.16 will be newer than Firefox 3.0.0, also, but have a lower
number, so there's more to it than that, but the branch identifier is,
I agree, key. The answer to "what Firefox are you running?" needs to
at least identify the major stream without requiring someone to
consult a Rosetta calendar-stone, for reasons of inter-user
communication as well as the obvious support cases. (Localizing
version identifiers, as would be required if we went to a date-based
system, also spooks me a bit, I must say.)

Mike

Reply all
Reply to author
Forward
0 new messages