Firefox version numbers and funness on #ubuntu

Corey Burger corey.burger at
Thu Apr 21 13:59:16 CDT 2005

On 4/21/05, Kent Nyberg <nyberg.kent at> wrote:
> tor 2005-04-21 klockan 10:36 -0700 skrev Corey Burger:
> > Hello all,
> >
> > I spend a lot of time on #ubuntu and the forums, generally answering
> > the same question ten times an hour. Anyway, one of the biggest things
> > that I hear is, where is FF 1.0.3?
> >
> > Now, I happen to know that most of the security fixes are backported,
> > but most people don't know that. If we appear to be unresponsive on FF
> > security, this can create a feeling of insecurity amongst users and a
> > backlash of "we aren't keeping our security up to date". Often the
> > appearance of security is more important in the average users eyes
> > than actually security.
> >
> > I also realize that bumping version numbers is generally not something
> > Debian does, but Ubuntu is moving into a user market that Debian
> > doesn't have, that of Mom and Dad. They don't read change logs and
> > thus their only way of making sure they are up to date is looking at
> > app numbers, if they even get that far.
> >
> > IANAD,
> >
> > Corey
> >
> I am in a bit of a hurry right now, but as fare as I know the following
> seems like a fair deal:
> Mom and Dad are not likely to even know a lot about the latest
> security-problems regarding firefox, and other potential problems in the
> future. That is, they are not going to start up an IRC channel and ask
> on #ubuntu about why not firefox has the latest version.
> That problem aside, I think update-manager is a great tool!
> With that application, Mom and Dad can get a notice about the need to
> let update-manager install a new version of firefox wich will fix a
> security-problem.  That way, Mom and Dad both get to know about the
> potential problem, and get it fixed automaticly.
> As for the problems with version-numbers, it will probably confuse
> people no matter how much you tell what the policy is regarding
> backports of fixes and installing new upstream-version.  But perhaps
> some of them could be helped by actually telling the user via
> update-manager that a new version of firefox needs to be installed and
> that it fixes some security-problems. Perhaps even tell the user about
> the policy about backports of fixes, and that this is even more saner
> than installing a new upstream-version since that implies new untested
> code, and new untested code most likely brings new bugs.
> And perhaps the about-screen of application X which has backported fixes
> could mention them, so that the user know that for example X is at
> version x.y.z, but it has backports from x.y.z+1, and is at the same
> security-level.
> That way it cant confuse some one..  right?
> This way, if Mom and Dad read on that firefox version
> x.y.z has security bugs, and they check the about-dialog on firefox they
> will read that even though they might have version x.y.z that
> implies has some bugs, the dialog will tell them not to
> worry, since they are fixed.
> Great?

I have to say that it took me a while to understand that. However, I
think I boiled it down to that we should inform users that the fixes
have been backported.

Hmm, I must say I cannot agree with that. That kind of defeats the
purpose of numbering of software.

In addition to the above, why fill the their heads with junk they
don't need to know. Most users will not read it and won't understand
it. Bad security dialogs are one of the worst things you can do, as
they are probably worse than no security dialogs. Observe Windows for
that. However, they will understand that the number just went up and
that it is the same as the one on the website and thus they have the
latest version.

On the topic of untested code, there are two types of releases we have
to worry about. The FF was one of the easy kind, just a security fix.
In other words, there was (should be?) no code that wasn't backported.
A feature update is different.

Remember, 95% of this is about perception and usability.


More information about the ubuntu-devel mailing list