As was discussed at the delivery meeting yesterday, we're proposing to
change the version number of Shiretoko from 3.1 to 3.5.  The increase in
scope represented by TraceMonkey and Private Browsing, plus the sheer
volume of work that's gone into everything from video and layout to
places and the plugin service make it a larger increment than we
believe is reasonable to
label ".1".  3.5 will help set expectations better about the amount of
awesome that's packed into Shiretoko, and we expect uptake help from that as
well.

It's important to note that 3.5 represents a better labelling of our
*current* scope, and not an indication that we intend to significantly
increase this release's scope any further.

Beta 3 will be the last milestone release with the 3.1 version number, and
Firefox 3.5b4 will be the following one.  mozilla-central's Minefield
version will be changed to 3.6pre as a placeholder.  For an abundance of
clarity: this does not indicate that the next version will be called
"Firefox 3.6" when it's shipped.

The Gecko version number will remain 1.9.1 on the mozilla-1.9.1 branch, and
will remain 1.9.2 on mozilla-central for the foreseeable future.

Work is underway to make sure that we can get the version identifiers
updated in relevant places like AMO, bugzilla, crash-stats and tinderbox
with minimal disruption.  Those changes will start to roll out this week.

There has been a lot of great conversation over the last few weeks about how
to balance product cadence (and its attendant impact on users) with
web-technology delivery and support for multiple dependent products; I
expect more concrete proposals to manifest here in the coming weeks, as we
get Firefox 3.5 (woo!) closer to ship.

Mike

Hi all,

here's news from .planning that should be of interest to you.

On 05.03.2009 20:18 Uhr, Mike Shaver wrote:
> As was discussed at the delivery meeting yesterday, we're proposing to
> change the version number of Shiretoko from 3.1 to 3.5.  The increase in
> scope represented by TraceMonkey and Private Browsing, plus the sheer
> volume of work that's gone into everything from video and layout to
> places and the plugin service make it a larger increment than we
> believe is reasonable to
> label ".1".  3.5 will help set expectations better about the amount of
> awesome that's packed into Shiretoko, and we expect uptake help from that as
> well.
>
> It's important to note that 3.5 represents a better labelling of our
> *current* scope, and not an indication that we intend to significantly
> increase this release's scope any further.
>
> Beta 3 will be the last milestone release with the 3.1 version number, and
> Firefox 3.5b4 will be the following one.  mozilla-central's Minefield
> version will be changed to 3.6pre as a placeholder.  For an abundance of
> clarity: this does not indicate that the next version will be called
> "Firefox 3.6" when it's shipped.
>
> The Gecko version number will remain 1.9.1 on the mozilla-1.9.1 branch, and
> will remain 1.9.2 on mozilla-central for the foreseeable future.
>
> Work is underway to make sure that we can get the version identifiers
> updated in relevant places like AMO, bugzilla, crash-stats and tinderbox
> with minimal disruption.  Those changes will start to roll out this week.
>
> There has been a lot of great conversation over the last few weeks about how
> to balance product cadence (and its attendant impact on users) with
> web-technology delivery and support for multiple dependent products; I
> expect more concrete proposals to manifest here in the coming weeks, as we
> get Firefox 3.5 (woo!) closer to ship.
>
> Mike

In addition to this, there is no impact on either the new B4 nor the 
rename on what we intend to do with string freeze. There's more clarity 
on how we're going to take the remaining string changes that I have 
talked about in earlier posts.

The time between 3.1 B3 and 3.5 B4 will be something around 4-5 weeks, 
and we're going to get the remaining string changes in to the tree in 
the first two weeks, which should leave you with some 2-3 weeks to catch 
up. The total amount shouldn't exceed some 20 strings, at least that's 
what we target.

Once we have B3, we'll ask you to do outreach with blogs and stuff to 
get your testers on. There's going to be some exposure of B3 on the 
startpage snippets, too. Pascal?

I hope that you'll use the window we have here to polish your 
translation work and incorporate loads of community feedback.

I'm currently working on getting unchanged-strings pages up again, so 
that you can hunt down those, too.

Cheers

Axel

Mike Shaver wrote:
> As was discussed at the delivery meeting yesterday, we're proposing to

Sorry I missed this notice yesterday.  I don't think this change is 
helplful at this late date in the 3.1 work.

> change the version number of Shiretoko from 3.1 to 3.5.  The increase in
> scope represented by TraceMonkey and Private Browsing, plus the sheer
> volume of work that's gone into everything from video and layout to
> places and the plugin service make it a larger increment than we
> believe is reasonable to
> label ".1".  3.5 will help set expectations better about the amount of
> awesome that's packed into Shiretoko, and we expect uptake help from that as
> well.

As a PR move this is hard to understand. If you sit close you think, 
"Ok, 3.1 is slipping so they need to make the target bigger." From far way:
2.0.0.8
....
2.0.0.12
3.0.0
....
3.0.7
3.5

So what follows this trend?  (Seems silly on both extremes to me).

> 
> Work is underway to make sure that we can get the version identifiers
> updated in relevant places like AMO, bugzilla, crash-stats and tinderbox
> with minimal disruption.  Those changes will start to roll out this week.

Well out here in extensions land, we've been relying on the upcoming 
3.1. In fact we have been getting badgered to prepare for it.  Now its 
suddenly gone. Should I really renumber our extension and all our bug 
reports? Maybe I better wait to see what really ships?

Anyway I think a bit more build up would help make this surprise less 
unpleasant.

jjb

On 6/3/09 18:52, John J Barton wrote:
> Mike Shaver wrote:
>> As was discussed at the delivery meeting yesterday, we're proposing to
>
> Sorry I missed this notice yesterday. I don't think this change is
> helplful at this late date in the 3.1 work.
>
>> change the version number of Shiretoko from 3.1 to 3.5. The increase in
>> scope represented by TraceMonkey and Private Browsing, plus the sheer
>> volume of work that's gone into everything from video and layout to
>> places and the plugin service make it a larger increment than we
>> believe is reasonable to
>> label ".1". 3.5 will help set expectations better about the amount of
>> awesome that's packed into Shiretoko, and we expect uptake help from
>> that as
>> well.
>
> As a PR move this is hard to understand. If you sit close you think,
> "Ok, 3.1 is slipping so they need to make the target bigger." From far way:
> 2.0.0.8
> ...
> 2.0.0.12
> 3.0.0
> ...
> 3.0.7
> 3.5
>
> So what follows this trend? (Seems silly on both extremes to me).

The release will be 3.5. Security updates will be delivered as 3.5.1, 
3.5.2 etc. I believe the intention is to always use a 3 part version 
number in the future, Firefox 2 was the only exception to that.

>> Work is underway to make sure that we can get the version identifiers
>> updated in relevant places like AMO, bugzilla, crash-stats and tinderbox
>> with minimal disruption. Those changes will start to roll out this week.
>
> Well out here in extensions land, we've been relying on the upcoming
> 3.1. In fact we have been getting badgered to prepare for it. Now its
> suddenly gone. Should I really renumber our extension and all our bug
> reports? Maybe I better wait to see what really ships?

It isn't suddenly gone, it will just be called something different. It 
doesn't affect the timing of the release at all, so if you were relying 
on 3.1 you are now relying on 3.5. I'm not sure why you would need to 
renumber your extension based on this, unless you mean the maxVersion 
and that is a fairly simple change to the update manifest (or in the 
developer panel in AMO once they enable support for the new versions).

Dave

Dave Townsend wrote:
....
> It isn't suddenly gone, it will just be called something different. It 
> doesn't affect the timing of the release at all, so if you were relying 
> on 3.1 you are now relying on 3.5. I'm not sure why you would need to 
> renumber your extension based on this, unless you mean the maxVersion 
> and that is a fairly simple change to the update manifest (or in the 
> developer panel in AMO once they enable support for the new versions).

I suppose this all seems trivial from the inside. It's not the version 
checking that is any issue, it's the toll in human communications. Bug 
reports, email, news postings all refer to 3.1. These all refer to 
something that is now gone. Yes another version will come out called 
3.5, but '3.1' does not go away.

Not changing the Gecko numbers compounds the problem by the way, since 
..1 will not map to 3.1 means we have to keep track of the mapping rather 
than just drop numbers.

It's all annoyingly pointless.  So as I said airing this and listening 
to the rants ahead of time would make it easier to take.

jjb

This is a multi-part message in MIME format.
--------------080102000403010201060202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/6/09 11:29 AM, John J Barton wrote:
> I suppose this all seems trivial from the inside. It's not the version
> checking that is any issue, it's the toll in human communications. Bug
> reports, email, news postings all refer to 3.1. These all refer to
> something that is now gone. Yes another version will come out called
> 3.5, but '3.1' does not go away.
Might I suggest that you use codenames (Shiretoko) in the future then? 
Codenames are created for a reason.

> Not changing the Gecko numbers compounds the problem by the way, since
> .1 will not map to 3.1 means we have to keep track of the mapping rather
> than just drop numbers.
This isn't new.  Firefox 2 shipped on Gecko 1.8.1, Firefox 1.5 shipped 
on 1.8.0, etc.  It'll always be in the user agent, so I'm not sure why 
this is such an issue.

> It's all annoyingly pointless. So as I said airing this and listening to
> the rants ahead of time would make it easier to take.
Maybe it comes across as pointless from your perspective as an add-on 
developer, but try putting yourself in the shoes of, say, a user who is 
wondering why 3.0 -> 3.1 contains so many changes.

/sdwilsh

--------------080102000403010201060202--

On Fri, Mar 6, 2009 at 2:29 PM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
> Not changing the Gecko numbers compounds the problem by the way, since .1
> will not map to 3.1 means we have to keep track of the mapping rather than
> just drop numbers.

Firefox and Gecko versions aren't necessarily in numbering
synchronization -- in fact, FF3 is the first time they have been in
that numerical sync that I can recall. (FF 1.0 was 1.7.5,
1.1-which-became-1.5 was 1.8.0, FF2 was 1.8.1, right?)

> It's all annoyingly pointless.

I explained the point in my previous posts (and on the delivery
meeting); it seems pretty uncharitable to claim that there is no point
to it, even if you believe that there are downsides.  We know there
are downsides, as there are for virtually every interesting decision
we make in developing software.

> So as I said airing this and listening to
> the rants ahead of time would make it easier to take.

That's precisely why we put it on the agenda for the delivery meeting,
discussed it there, put it on devnews, and posted the proposal here.
It was also reported by a fair number of press folk, so I think it was
pretty visible.

The change isn't going to manifest in beta 3, so there are 6 weeks at
least before there's a released milestone.  This is not a coincidence.

Mike

Shawn Wilsher wrote:
> On 3/6/09 11:29 AM, John J Barton wrote:
>> I suppose this all seems trivial from the inside. It's not the version
>> checking that is any issue, it's the toll in human communications. Bug
>> reports, email, news postings all refer to 3.1. These all refer to
>> something that is now gone. Yes another version will come out called
>> 3.5, but '3.1' does not go away.
> Might I suggest that you use codenames (Shiretoko) in the future then? 
> Codenames are created for a reason.

That won't work here:
  this.ff3p1 = versionChecker.compare(appInfo.version, "3.1*") >= 0;

Plus it's not practical because users don't say that, they say 3.1.

> 
>> Not changing the Gecko numbers compounds the problem by the way, since
>> .1 will not map to 3.1 means we have to keep track of the mapping rather
>> than just drop numbers.
> This isn't new.  Firefox 2 shipped on Gecko 1.8.1, Firefox 1.5 shipped 
> on 1.8.0, etc.  It'll always be in the user agent, so I'm not sure why 
> this is such an issue.

Irrespective of history, I'm just reporting to you that this is one of 
the things that makes mozilla hard to work with.

> 
>> It's all annoyingly pointless. So as I said airing this and listening to
>> the rants ahead of time would make it easier to take.
> Maybe it comes across as pointless from your perspective as an add-on 
> developer, but try putting yourself in the shoes of, say, a user who is 
> wondering why 3.0 -> 3.1 contains so many changes.

This part I don't get: why wouldn't users be delighted with a bulging 
new 3.1?

jjb

Mike Shaver wrote:
>> So as I said airing this and listening to
>> the rants ahead of time would make it easier to take.
> 
> That's precisely why we put it on the agenda for the delivery meeting,
> discussed it there, put it on devnews, and posted the proposal here.
> It was also reported by a fair number of press folk, so I think it was
> pretty visible.
> 
Ah, you posted the devnews yesterday. Like I said, I'm sorry I missed it 
while it was still a proposal. Then my complaints would be part of the 
downside, you'd say "sorry" and that would be it.

jjb

On 6/3/09 19:59, John J Barton wrote:
>>> It's all annoyingly pointless. So as I said airing this and listening to
>>> the rants ahead of time would make it easier to take.
>> Maybe it comes across as pointless from your perspective as an add-on
>> developer, but try putting yourself in the shoes of, say, a user who
>> is wondering why 3.0 -> 3.1 contains so many changes.
>
> This part I don't get: why wouldn't users be delighted with a bulging
> new 3.1?

More to the point, why would users know there is so much new stuff for 
them to enjoy when the release is only a .1 increment?

This is a multi-part message in MIME format.
--------------050705020508030204040308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/6/09 11:59 AM, John J Barton wrote:
>> On 3/6/09 11:29 AM, John J Barton wrote:
>>> I suppose this all seems trivial from the inside. It's not the version
>>> checking that is any issue, it's the toll in human communications. Bug
>>> reports, email, news postings all refer to 3.1. These all refer to
>>> something that is now gone. Yes another version will come out called
>>> 3.5, but '3.1' does not go away.
>> Might I suggest that you use codenames (Shiretoko) in the future then?
>> Codenames are created for a reason.
>
> That won't work here:
> this.ff3p1 = versionChecker.compare(appInfo.version, "3.1*") >= 0;
I'm a bit confused here.  You said it is not version checking that is a 
problem, but that it is human communication that is the issue.  I then 
suggested code names, and then you argued that that doesn't work in 
version checking code.  It almost looks like you are arguing for the 
sake of arguing here, which I don't think you actually mean to do.  Can 
you please clarify?

> Plus it's not practical because users don't say that, they say 3.1.
Perhaps that's because developers say 3.1, so that's what users 
associate?  This seems a lot like a chicken and egg problem, honestly.

> This part I don't get: why wouldn't users be delighted with a bulging
> new 3.1?
The same kind of reasons why some users don't like the new location bar 
in Firefox 3.0.  Big changes are scary to users.  Small version bumps 
imply that there aren't many changes, whereas bigger ones imply that 
there will be more.  It's psychological.

Cheers,

Shawn

--------------050705020508030204040308--

I've updated the docs on MDC to refer to the release as 3.5 everywhere
I could find.  There are likely spots here and there I missed; if you
see one, feel free to tweak it.

I've left the tags as "Firefox 3.1" for now -- Mindtouch is making me
a tool to fix those automatically.  Woohoo!

Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
http://www.bitstampede.com/

Shawn Wilsher wrote:
> On 3/6/09 11:59 AM, John J Barton wrote:
>>> On 3/6/09 11:29 AM, John J Barton wrote:
>>>> I suppose this all seems trivial from the inside. It's not the version
>>>> checking that is any issue, it's the toll in human communications. Bug
>>>> reports, email, news postings all refer to 3.1. These all refer to
>>>> something that is now gone. Yes another version will come out called
>>>> 3.5, but '3.1' does not go away.
>>> Might I suggest that you use codenames (Shiretoko) in the future then?
>>> Codenames are created for a reason.
>>
>> That won't work here:
>> this.ff3p1 = versionChecker.compare(appInfo.version, "3.1*") >= 0;
> I'm a bit confused here.  You said it is not version checking that is a 
> problem, but that it is human communication that is the issue.  I then 
> suggested code names, and then you argued that that doesn't work in 
> version checking code.  It almost looks like you are arguing for the 
> sake of arguing here, which I don't think you actually mean to do.  Can 
> you please clarify?

I was replying to Dave's suggestion that the maxVersion number was easy 
to change; there are more impacts than that, including primarily human 
communications but also code changes. Hope that is clearer.

> 
>> Plus it's not practical because users don't say that, they say 3.1.
> Perhaps that's because developers say 3.1, so that's what users 
> associate?  This seems a lot like a chicken and egg problem, honestly.

Ok, but I can't fix it.

> 
>> This part I don't get: why wouldn't users be delighted with a bulging
>> new 3.1?
> The same kind of reasons why some users don't like the new location bar 
> in Firefox 3.0.  Big changes are scary to users.  Small version bumps 
> imply that there aren't many changes, whereas bigger ones imply that 
> there will be more.  It's psychological.

But the new location bar was introduced with a major number change, 2.0 
-> 3.0. Some people still didn't like it. So the number bit had nothing 
to do with it.  It's not psychological, they just don't like it.

Let's face it, folks will complain about changes no matter what you 
number them. I offer my posts here as evidence ;-(.

jjb

The problem as I see it is that there is no consistent numbering
scheme.  I've always found it easier to follow in this sort of method:
The first number represents a long term goal achievement (anything
that would require breaking current release branch's API, unless for
security, or something like 'reach full HTML5 support'); second number
is the development phase toward fixing bugs on the current branch, or
backporting trunk additions that don't break the API, with even
numbers being stable releases and odd numbers being development; and
third is for security updates and the third number only shows up with
an even second number since development versions are in-flux anyways.
Trunk is then where development occurs for the next long term goal
achievement.  I'm not familiar with the API changes, etc, but I would
hazard a guess that using this method, there would be 3.0.x security
releases as there are currently, 3.1 development releases as there are
currently, and upcoming release would be 3.2, followed by 3.2.x
security releases and 3.3 development branch.

I think extension developers would find this numbering scheme more
beneficial.  Then they wouldn't have to worry as much about their
extensions breaking just because of maxVersion, since API breaks would
typically occur at the first number.  That way, maxVersion 3.* would
cover until the next milestone.  And it would be easier on the user
base as well, because there are a lot of current extensions with
maxVersion as their only issues.

Changing numbers now IMHO gives the impression that planning isn't
really a strong suit in Firefox development, even if it is well
documented.  And also, I thought the point of version numbers was
precisely for planning purposes, and not for some arbitrary
interpretation by an end-user.  And if numbering is rather arbitrary,
why not make it more beneficial for the extension developers, who are
responsible in large part for the popularity of firefox?

I'm just a user and one time extension developer, so I'm not trying to
enforce this or anything, I only wanted to leave my two cents worth.

On Sat, Mar 7, 2009 at 02:05, eternalsword <micah.bucy@gmail.com> wrote:
> The problem as I see it is that there is no consistent numbering
> scheme. =A0I've always found it easier to follow in this sort of method:
> The first number represents a long term goal achievement (anything
> that would require breaking current release branch's API, unless for
> security, or something like 'reach full HTML5 support'); second number
> is the development phase toward fixing bugs on the current branch, or
> backporting trunk additions that don't break the API, with even
> numbers being stable releases and odd numbers being development; and
> third is for security updates and the third number only shows up with
> an even second number since development versions are in-flux anyways.
> Trunk is then where development occurs for the next long term goal
> achievement. =A0I'm not familiar with the API changes, etc, but I would
> hazard a guess that using this method, there would be 3.0.x security
> releases as there are currently, 3.1 development releases as there are
> currently, and upcoming release would be 3.2, followed by 3.2.x
> security releases and 3.3 development branch.

Mozilla has no history of using the odd/even system. Every time it is
brought up a dev comes along and says Mozilla has not used that scheme
in the past and they are not about to switch just because it is
popular in the Linux world.

On Fri, 06 Mar 2009 12:40:55 -0800, Shawn Wilsher wrote:
> On 3/6/09 11:59 AM, John J Barton wrote:

>> This part I don't get: why wouldn't users be delighted with a bulging
>> new 3.1?

I agree with John. All this version inflation just makes Mozilla look
like one of those proprietary companies making commercial software,
which it isn't.

> The same kind of reasons why some users don't like the new location bar 
> in Firefox 3.0.  Big changes are scary to users.  Small version bumps 
> imply that there aren't many changes, whereas bigger ones imply that 
> there will be more.  It's psychological.

So how many of those changes are user facing vs how many are developer
(web and extension) facing?

Speaking as an extension developer, while bumping the maxVersion for one
extension is no big deal, we have been telling our end users that our
extensions are now 3.1 compatible and then now to tell them you need yet
another version for the upcoming 3.5 is slightly annoying. Multiply that
by at least 10,000 (One of my extensions has an ID of exactly 10000 on AMO).

Phil

-- 
Philip Chee <philip@aleytys.pc.my>, <philip.chee@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.

On 7/3/09 07:05, eternalsword wrote:
> The problem as I see it is that there is no consistent numbering
> scheme.  I've always found it easier to follow in this sort of method:
> The first number represents a long term goal achievement (anything
> that would require breaking current release branch's API, unless for
> security, or something like 'reach full HTML5 support'); second number
> is the development phase toward fixing bugs on the current branch, or
> backporting trunk additions that don't break the API, with even
> numbers being stable releases and odd numbers being development; and
> third is for security updates and the third number only shows up with
> an even second number since development versions are in-flux anyways.
> Trunk is then where development occurs for the next long term goal
> achievement.  I'm not familiar with the API changes, etc, but I would
> hazard a guess that using this method, there would be 3.0.x security
> releases as there are currently, 3.1 development releases as there are
> currently, and upcoming release would be 3.2, followed by 3.2.x
> security releases and 3.3 development branch.

We actually have very close to this already, except that your example of 
the second number doesn't really apply to us. We don't code or backport 
general fixes to previous releases. So we have the first two digits for 
the "release version" if you like and the third for security and 
stability fixes, none of which should break APIs. We basically cannot 
take API breaking changes in a release branch since it would kill too 
many extensions.

> I think extension developers would find this numbering scheme more
> beneficial.  Then they wouldn't have to worry as much about their
> extensions breaking just because of maxVersion, since API breaks would
> typically occur at the first number.  That way, maxVersion 3.* would
> cover until the next milestone.  And it would be easier on the user
> base as well, because there are a lot of current extensions with
> maxVersion as their only issues.

Extension authors shouldn't have to worry about their maxVersion on 
release branches, the 3rd digit is the only one that should change so 
using 3.0.* should indeed cover them till the next milestone where APIs 
are liable to change.

> Changing numbers now IMHO gives the impression that planning isn't
> really a strong suit in Firefox development, even if it is well
> documented.

We could certainly get better at planning for sure, but of course 
planning is basically about looking into a crystal ball and predicting 
the future. You don't necessarily see that one of the big features you 
wanted was going to take longer to iron out, allowing possibly other 
work that is ready to make it in. You don't see the awesome work of 
contributors working day and night to land large unexpected features. We 
could make different decisions when these things come up, maybe drop the 
features and get the release out on time, that's a difficult call to 
make each time though.

> And also, I thought the point of version numbers was
> precisely for planning purposes, and not for some arbitrary
> interpretation by an end-user.

Why would it be useful for planning purposes? Planned releases with 
codenames and a good understanding of the timescales and scope of change 
wanted is useful for planning. The version should certainly be derived 
from that but it shouldn't be the driver of it. And since the version is 
derived from that, when the plan changes so could the version.

> And if numbering is rather arbitrary,
> why not make it more beneficial for the extension developers, who are
> responsible in large part for the popularity of firefox?

Numbering is mostly arbitrary IMO. It is a subjective measurement of the 
amount of work that went into a release, something users and developers 
can use to get a handle on what might be involved in upgrading. I'm not 
sure how we could make it more beneficial to extension developers 
though, other than simply trying to be better at making tat subjective 
measurement, something that is part of the rationale for this change.

On 07.03.2009 08:05, eternalsword wrote:
> [...]  second number
> is the development phase toward fixing bugs on the current branch, or
> backporting trunk additions that don't break the API, with even
> numbers being stable releases and odd numbers being development; [...]
> I'm not familiar with the API changes, etc, but I would
> hazard a guess that using this method, there would be 3.0.x security
> releases as there are currently, 3.1 development releases as there are
> currently, and upcoming release would be 3.2, followed by 3.2.x
> security releases and 3.3 development branch.
>
> I think extension developers would find this numbering scheme more
> beneficial.  Then they wouldn't have to worry as much about their
> extensions breaking just because of maxVersion, since API breaks would
> typically occur at the first number.  That way, maxVersion 3.* would
> cover until the next milestone.

Extensions use all sorts of private interfaces and stuff that doesn't 
even deserve the name "interface". Basically, we couldn't touch the 
front-end with a secondary number change. 3.1 wouldn't have been 
possible that way.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7F9B1C6CCECE10DBBBA2203D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 03/07/2009 04:25 AM, Dave Townsend wrote:
>> I think extension developers would find this numbering scheme more
>> beneficial.  Then they wouldn't have to worry as much about their
>> extensions breaking just because of maxVersion, since API breaks would=

>> typically occur at the first number.  That way, maxVersion 3.* would
>> cover until the next milestone.  And it would be easier on the user
>> base as well, because there are a lot of current extensions with
>> maxVersion as their only issues.
>
> Extension authors shouldn't have to worry about their maxVersion on
> release branches, the 3rd digit is the only one that should change so
> using 3.0.* should indeed cover them till the next milestone where
> APIs are liable to change.=20
For 3.5  or 3.2 they wouldnt be able to use 3.0*. As i recall that will
only cover 3.0 security releases so in install.rdf it would be closer to
3.5* or 3.2*.
As for the changes in versions, does this affect release times or is 3.5
still set to be released before 3.2?
If not maybe bumping 3.2 to 3.6 or something like that this way it all
stays inline. releasing 3.5 than releasing 3.2 might (most likely will)
confuse end users.
That would also caaause an issue with extensions devs i think. if they
bump max version to 3.5 but the code changes in 3.2 might conflict with
code in extensions.

By no means am i against the version changes i just wanted to point out
something no one has done from what i have read.

--=20
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III



--------------enig7F9B1C6CCECE10DBBBA2203D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmygrwACgkQ9Plt3HZNXhPRCACeKmiZp2f9SqNo5hIIAEJdkhZ7
Fg8AoJnlbXHbNcHTDj3PI8jPaDn4bUT6
=oRX6
-----END PGP SIGNATURE-----

--------------enig7F9B1C6CCECE10DBBBA2203D--

On Sat, Mar 7, 2009 at 9:20 AM, John Vivirito
<mozilla.extensions.dev@gmail.com> wrote:
> As for the changes in versions, does this affect release times or is 3.5
> still set to be released before 3.2?

No change in release times due to the numbering change.

> If not maybe bumping 3.2 to 3.6 or something like that this way it all
> stays inline. releasing 3.5 than releasing 3.2 might (most likely will)
> confuse end users.

Yes, that would be confusing indeed!  From my original post in this thread:

Beta 3 will be the last milestone release with the 3.1 version number, and
Firefox 3.5b4 will be the following one.  mozilla-central's Minefield
version will be changed to 3.6pre as a placeholder.  For an abundance of
clarity: this does not indicate that the next version will be called
"Firefox 3.6" when it's shipped.

The Firefox after 3.5 might be 3.6 or 4 or Pro Extreme or Mauve, but
it won't be a number that sorts lower than 3.5, I assure you. :)

Mike

On Mar 7, 9:20=A0am, John Vivirito <mozilla.extensions....@gmail.com>
wrote:

> That would also caaause an issue with extensions devs i think. if they
> bump max version to 3.5 but the code changes in 3.2 might conflict with
> code in extensions.

This is absolutely a huge concern.  The only solution to avoiding a
conflict with an extension or theme developed for 3.1 is not to merely
bump the maxVersion to 3.5.* for compatibility with Shiretoko 3.5, but
to also bump the minVersion to 3.5b4pre or whatever number precisely
identifies the first 3.5 build so that installation is not possible on
anything identified as 3.2.*, and of course 3.6.*.

On Mar 6, 2:59=A0pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> >> Not changing the Gecko numbers compounds the problem by the way, since
> >> .1 will not map to 3.1 means we have to keep track of the mapping rath=
er
> >> than just drop numbers.
> > This isn't new. =A0Firefox 2 shipped on Gecko 1.8.1, Firefox 1.5 shippe=
d
> > on 1.8.0, etc. =A0It'll always be in the user agent, so I'm not sure wh=
y
> > this is such an issue.
>
> Irrespective of history, I'm just reporting to you that this is one of
> the things that makes mozilla hard to work with.
>
> >> It's all annoyingly pointless. So as I said airing this and listening =
to
> >> the rants ahead of time would make it easier to take.
> > Maybe it comes across as pointless from your perspective as an add-on
> > developer, but try putting yourself in the shoes of, say, a user who is
> > wondering why 3.0 -> 3.1 contains so many changes.
>
> This part I don't get: why wouldn't users be delighted with a bulging
> new 3.1?
>
> jjb

I agree. Since version 1.0, the version numbers have gone 1.0->1.5-
>2.0->3.0->3.5. Both x.5 releases were originally developed as x.1,
but were deemed "bigger in scope" than originally planned. However, as
far as I can tell, the only strictly user-facing improvements in
Firefox 3.1/3.5 are Private Browsing and better tab drag-and-drop. (I
may have missed something, but it's hard to tell, because it's not
documented all in one place.) All of the other (many) improvements
have been in the backend, where they would need to be implemented by a
specific web developer or extension author in order to be useful. So,
as far as I can tell, the user will not see this next release as a
"bulging". There is no real major change that will disrupt user
experience, as there was with the AwesomeBar.

As I said, most of the new features have been implemented in the
backend. As far as I know, that means they were implemented in Gecko,
not specifically Firefox. Yet Gecko's version number is not changing.
This doesn't make much sense to me. Perhaps I'm mistaken?

And I would see Gecko and Firefox versions finally synching as a good
thing. I have expressed from the beginning my support for the fact
that [Gecko 1.9].x =3D=3D [Firefox 3].x. Why would effort be made to
specifically go back away from that?

I just don't get it, and I would like to express a strong -1 for
upping the version number to 3.5.

On Mar 7, 2009, at 7:34 PM, Gordon P. Hemsley wrote:
> And I would see Gecko and Firefox versions finally synching as a good
> thing. I have expressed from the beginning my support for the fact
> that [Gecko 1.9].x == [Firefox 3].x. Why would effort be made to
> specifically go back away from that?

Gecko numbers have never really been "in sync" with major Firefox  
versions (maintenance releases are clearly different here). We have  
major Gecko versions and major Firefox versions.

e.g.:

  * Firefox 1 == Gecko 1.7
  * Firefox 1.5 == Gecko 1.8.0
  * Firefox 2 == Gecko 1.8.1
  * Firefox 3 == Gecko 1.9.0
  * Firefox 3.5 == Gecko 1.9.1

There's nothing wrong or inconsistent about this. Gecko version  
numbers aren't really "user-facing" either, so they don't really need  
to be in sync with Firefox version numbers.

Regardless, Gecko releases are not the same as Firefox releases. Let's  
not confuse the two in this discussion.

-Sam

On Mar 7, 10:46=A0pm, Samuel Sidler <s...@mozilla.com> wrote:
> On Mar 7, 2009, at 7:34 PM, Gordon P. Hemsley wrote:
>
> > And I would see Gecko and Firefox versions finally synching as a good
> > thing. I have expressed from the beginning my support for the fact
> > that [Gecko 1.9].x =3D=3D [Firefox 3].x. Why would effort be made to
> > specifically go back away from that?
>
> Gecko numbers have never really been "in sync" with major Firefox =A0
> versions (maintenance releases are clearly different here). We have =A0
> major Gecko versions and major Firefox versions.
>
> e.g.:
>
> =A0 * Firefox 1 =3D=3D Gecko 1.7
> =A0 * Firefox 1.5 =3D=3D Gecko 1.8.0
> =A0 * Firefox 2 =3D=3D Gecko 1.8.1
> =A0 * Firefox 3 =3D=3D Gecko 1.9.0
> =A0 * Firefox 3.5 =3D=3D Gecko 1.9.1
>
> There's nothing wrong or inconsistent about this. Gecko version =A0
> numbers aren't really "user-facing" either, so they don't really need =A0
> to be in sync with Firefox version numbers.
>
> Regardless, Gecko releases are not the same as Firefox releases. Let's =
=A0
> not confuse the two in this discussion.
>
> -Sam

I'm aware that they haven't been in sync before. But I would think
it'd be beneficial for them to finally be, wouldn't it? Perhaps not to
the end user, but for developers (of various kinds)?

Is Gecko actually released independently of Firefox, or does it just
sit in the repository with tags? And how much of Firefox is Gecko, and
how much isn't? Particularly, with regard to the new features in
Shiretoko? I don't think the distinction should be noted until those
details are specified.

Gordon

On 8/3/09 02:27, mozillacat@gmail.com wrote:
> On Mar 7, 9:20 am, John Vivirito<mozilla.extensions....@gmail.com>
> wrote:
>
>> That would also caaause an issue with extensions devs i think. if they
>> bump max version to 3.5 but the code changes in 3.2 might conflict with
>> code in extensions.
> This is absolutely a huge concern.  The only solution to avoiding a
> conflict with an extension or theme developed for 3.1 is not to merely
> bump the maxVersion to 3.5.* for compatibility with Shiretoko 3.5, but
> to also bump the minVersion to 3.5b4pre or whatever number precisely
> identifies the first 3.5 build so that installation is not possible on
> anything identified as 3.2.*, and of course 3.6.*.

I don't think this is a major concern since trunk will be bumped to 
3.6a1pre at the same time the branch is changed to 3.5b4pre. Certainly 
it is possible that people using older versions of trunk might end up 
installing a 3.5 compatible add-on, but really most people there will be 
auto-updating to new nightlies all the time. Anyone staying fixed on 
older versions have their own problems to content with anyway.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCF50AA7C02B00164528037EF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 03/07/2009 10:01 AM, Mike Shaver wrote:
> On Sat, Mar 7, 2009 at 9:20 AM, John Vivirito
> <mozilla.extensions.dev@gmail.com> wrote:
>  =20
>> As for the changes in versions, does this affect release times or is 3=
=2E5
>> still set to be released before 3.2?
>>    =20
> No change in release times due to the numbering change.
>
>  =20
>> If not maybe bumping 3.2 to 3.6 or something like that this way it all=

>> stays inline. releasing 3.5 than releasing 3.2 might (most likely will=
)
>> confuse end users.
>>    =20
> Yes, that would be confusing indeed!  From my original post in this thr=
ead:
>
> Beta 3 will be the last milestone release with the 3.1 version number, =
and
> Firefox 3.5b4 will be the following one.  mozilla-central's Minefield
> version will be changed to 3.6pre as a placeholder.  For an abundance o=
f
> clarity: this does not indicate that the next version will be called
> "Firefox 3.6" when it's shipped.
>
> The Firefox after 3.5 might be 3.6 or 4 or Pro Extreme or Mauve, but
> it won't be a number that sorts lower than 3.5, I assure you. :)
>
> Mike
>
>  =20
Thank your for clairfing

> On Mar 7, 9:20 am, John Vivirito <mozilla.extensions....@gmail.com>
> wrote:
>
>  =20
>> > That would also caaause an issue with extensions devs i think. if th=
ey
>> > bump max version to 3.5 but the code changes in 3.2 might conflict w=
ith
>> > code in extensions.
>>    =20
> This is absolutely a huge concern.  The only solution to avoiding a
> conflict with an extension or theme developed for 3.1 is not to merely
> bump the maxVersion to 3.5.* for compatibility with Shiretoko 3.5, but
> to also bump the minVersion to 3.5b4pre or whatever number precisely
> identifies the first 3.5 build so that installation is not possible on
> anything identified as 3.2.*, and of course 3.6.*.
>  =20
By bumping the minversion will cause incompatibility for <3.5.*
Does this mean that extensions for 3.0.X will be provided separate from
>3.0?

=20
> On Mar 7, 10:46 pm, Samuel Sidler <s...@mozilla.com> wrote:
>  =20
>> > On Mar 7, 2009, at 7:34 PM, Gordon P. Hemsley wrote:
>> >
>>    =20
>>> > > And I would see Gecko and Firefox versions finally synching as a =
good
>>> > > thing. I have expressed from the beginning my support for the fac=
t
>>> > > that [Gecko 1.9].x =3D=3D [Firefox 3].x. Why would effort be made=
 to
>>> > > specifically go back away from that?
>>>      =20
>> >
>> > Gecko numbers have never really been "in sync" with major Firefox =20
>> > versions (maintenance releases are clearly different here). We have =
=20
>> > major Gecko versions and major Firefox versions.
>> >
>> > e.g.:
>> >
>> >   * Firefox 1 =3D=3D Gecko 1.7
>> >   * Firefox 1.5 =3D=3D Gecko 1.8.0
>> >   * Firefox 2 =3D=3D Gecko 1.8.1
>> >   * Firefox 3 =3D=3D Gecko 1.9.0
>> >   * Firefox 3.5 =3D=3D Gecko 1.9.1
>> >
>> > There's nothing wrong or inconsistent about this. Gecko version =20
>> > numbers aren't really "user-facing" either, so they don't really nee=
d =20
>> > to be in sync with Firefox version numbers.
>> >
>> > Regardless, Gecko releases are not the same as Firefox releases. Let=
's =20
>> > not confuse the two in this discussion.
>> >
>> > -Sam
>>    =20
> I'm aware that they haven't been in sync before. But I would think
> it'd be beneficial for them to finally be, wouldn't it? Perhaps not to
> the end user, but for developers (of various kinds)?
>
> Is Gecko actually released independently of Firefox, or does it just
> sit in the repository with tags? And how much of Firefox is Gecko, and
> how much isn't? Particularly, with regard to the new features in
> Shiretoko? I don't think the distinction should be noted until those
> details are specified.
>
> Gordon
>  =20
I can understand the concern that gecko versions are not the same as
Firefox, however gecko is NOT just used for Firefox but also for
Seamonkey and others. So syncing gecko with Firefox versions, I dont see
any reason.

> I don't think this is a major concern since trunk will be bumped to
> 3.6a1pre at the same time the branch is changed to 3.5b4pre. Certainly
> it is possible that people using older versions of trunk might end up
> installing a 3.5 compatible add-on, but really most people there will
> be auto-updating to new nightlies all the time. Anyone staying fixed
> on older versions have their own problems to content with anyway.=20
In the case of Ubuntu we don't auto-update and I'm sure is same for most
Linux distributions=20

--=20
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III



--------------enigCF50AA7C02B00164528037EF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmzyW4ACgkQ9Plt3HZNXhN6rgCfU3uTHKvWX19VAprJBO2TPKKJ
2coAoKvVrmLrCDQB8ejnLty55vz7SQPn
=JrPY
-----END PGP SIGNATURE-----

--------------enigCF50AA7C02B00164528037EF--

On Sun, Mar 8, 2009 at 3:34 PM, John Vivirito wrote:
> In the case of Ubuntu we don't auto-update and I'm sure is same for most
> Linux distributions

if you leave users w/ alpha versions of software w/o auto updating,
then your'e being reckless. and i'm perfectly fine w/ your users
flaying you for such actions.

On Mar 8, 4:40=A0am, Dave Townsend <dtowns...@mozilla.com> wrote:
> On 8/3/09 02:27, mozilla...@gmail.com wrote:
>
> > On Mar 7, 9:20 am, John Vivirito<mozilla.extensions....@gmail.com>
> > wrote:
>
> >> That would also caaause an issue with extensions devs i think. if they
> >> bump max version to 3.5 but the code changes in 3.2 might conflict wit=
h
> >> code in extensions.
> > This is absolutely a huge concern. =A0The only solution to avoiding a
> > conflict with an extension or theme developed for 3.1 is not to merely
> > bump the maxVersion to 3.5.* for compatibility with Shiretoko 3.5, but
> > to also bump the minVersion to 3.5b4pre or whatever number precisely
> > identifies the first 3.5 build so that installation is not possible on
> > anything identified as 3.2.*, and of course 3.6.*.
>
> I don't think this is a major concern since trunk will be bumped to
> 3.6a1pre at the same time the branch is changed to 3.5b4pre. Certainly
> it is possible that people using older versions of trunk might end up
> installing a 3.5 compatible add-on, but really most people there will be
> auto-updating to new nightlies all the time. Anyone staying fixed on
> older versions have their own problems to content with anyway.

I agree with you, Dave.  That's why I have opted to bump the
maxVersion and keep minVersion as is.  I figure anyone testing a 3.2
build (or any test build for that matter) before updating to 3.6 has
learned to expect compatibility issues along the way.  Besides, in my
case I can only think of one extension where problems may be seen.  As
long as all is good with the milestones, all is good with me.

- CatThief

On 08.03.2009 21:29, timeless wrote:
> On Sun, Mar 8, 2009 at 3:34 PM, John Vivirito wrote:
>> In the case of Ubuntu we don't auto-update and I'm sure is same for most
>> Linux distributions
> if you leave users w/ alpha versions of software w/o auto updating,
> then your'e being reckless. and i'm perfectly fine w/ your users
> flaying you for such actions.

Maybe he was just meaning that Ubuntu doesn't use the Mozilla Updater, 
but relies on its own package mechanism to deliver new Mozilla testing 
milestones?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7569A70FED0FA724C1989FDC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 03/09/2009 05:48 AM, Thomas Stache wrote:
> On 08.03.2009 21:29, timeless wrote:
>> On Sun, Mar 8, 2009 at 3:34 PM, John Vivirito wrote:
>>> In the case of Ubuntu we don't auto-update and I'm sure is same for
>>> most
>>> Linux distributions
>> if you leave users w/ alpha versions of software w/o auto updating,
>> then your'e being reckless. and i'm perfectly fine w/ your users
>> flaying you for such actions.
>
> Maybe he was just meaning that Ubuntu doesn't use the Mozilla Updater,
> but relies on its own package mechanism to deliver new Mozilla testing
> milestones?
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
We update our packages for Ubuntu archives so you are never left with
old versions. Within days of mozilla release we push our package to
archives.

--=20
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III



--------------enig7569A70FED0FA724C1989FDC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkm1Q8cACgkQ9Plt3HZNXhM73wCgiJ2w/pZXjwiEIen7Lm982i2c
TKcAn210ONfMG/hySbyPAIu4jCQxRa8b
=9H9G
-----END PGP SIGNATURE-----

--------------enig7569A70FED0FA724C1989FDC--

John Vivirito wrote on 07.03.2009 15:20 Uhr:

> As for the changes in versions, does this affect release times or is 3.5
> still set to be released before 3.2?
> If not maybe bumping 3.2 to 3.6 or something like that this way it all
> stays inline. releasing 3.5 than releasing 3.2 might (most likely will)
> confuse end usaers.

That's the plan. See
https://wiki.mozilla.org/Firefox3.1/3.5#Roll-out_Timeline

Henrik

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4DC6322CDD3F80486425B700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 03/11/2009 02:49 AM, Henrik Skupin wrote:
> John Vivirito wrote on 07.03.2009 15:20 Uhr:
>
>  =20
>> As for the changes in versions, does this affect release times or is 3=
=2E5
>> still set to be released before 3.2?
>> If not maybe bumping 3.2 to 3.6 or something like that this way it all=

>> stays inline. releasing 3.5 than releasing 3.2 might (most likely will=
)
>> confuse end usaers.
>>    =20
> That's the plan. See
> https://wiki.mozilla.org/Firefox3.1/3.5#Roll-out_Timeline
>
> Henrik
> _______________________________________________
> dev-planning mailing list
> dev-planning@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
>  =20
Thanks for the link.

--=20
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III



--------------enig4DC6322CDD3F80486425B700
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkm3mScACgkQ9Plt3HZNXhN+8ACfY3ISPz75yDrog6s5IN7+dhy1
y14AoJdsAXHqItjNCNDjVhOJ7qQekiRn
=TXzH
-----END PGP SIGNATURE-----

--------------enig4DC6322CDD3F80486425B700--

this is, quite honestly, pointless talk - and i say this as a user.

i love my firefox, however i HATE what is has become: a competitive,
commercial-like piece of software. we shouldnt be implementing changes
just because chrome has this and firefox doesn't: we should be
implementing features we think we need. and honestly, spend more time
working on releasing 3.1 than talking about its version number...

i personally love this numbering system:

Y.x.x
x.Y.x
x.x.Y

in the first row, Y marks a major milestone, as the jump from 2 -> 3.
a change in the second Y would be functioning differences / major
feature additions, however no new interface etc. that the first change
would include. if Y changes in the third row, it indicates a small
security update. works for the ipod touch, should work for firefox.

and this way, users would know what to expect from an upcoming change.
i will be one of many firefox users scratching my head and wondering
at the logic in a 3.0.8 -> 3.5 leap.

just my 2 cents.

Mike Shaver wrote:
> As was discussed at the delivery meeting yesterday, we're proposing to
> change the version number of Shiretoko from 3.1 to 3.5.

What=92s in a name? that which we call a rose
By any other name would smell as sweet;
    Romeo and Juliet (William Shakespeare)


Given that old wisdom, why do so many people shed tears about this=20
decision? Either it's a good product or it's not, either you like it or=20
don't, either you support the team or don't. As long as the next release =

has a higher number than the last, everything else is a marketing=20
decision, and so far the Firefox marketing people have done a very good=20
job to bring a product with the Mozilla philosophy to a rapidly=20
increasing number of people. Don't you trust them? If you do, could you=20
stop whining?

Robert Kaiser


P.S.: Jumping to X.5 for such steps is a long-going tradition, dating=20
back to the times when Mozilla still was only a codename for Netscape's=20
browsers.

On 03/13/2009 02:19 AM, bthaxor@gmail.com wrote:
 > this is, quite honestly, pointless talk - and i say this as a user.
[snip]
 > and honestly, spend more time
 > working on releasing 3.1 than talking about its version number...

Agreed.  Why continue harping on it, then? :)

 > i personally love this numbering system:
 >
 > Y.x.x
....
 > i will be one of many firefox users scratching my head and wondering
 > at the logic in a 3.0.8 ->  3.5 leap.

I think you might misunderstand -- this is an upgrade from 3.0.x to 
3.5.0 (not to 3.5).  Security releases will be 3.5.1, 3.5.2, etc.  (as 
mentioned in the third post on this thread)

Or, if you're wondering about why it's a "5", see the initial post on 
this thread, from Mike Shaver.

~Daniel

oh believe me, i do not misunderstand anything. i full understand why
the leap was made, i know security updates will be 3.5.x, i know why
it is a '5' - my concern is that the average computer user won't
understand the logic in 3.0.8 -> 3.5.0.

then again, i dont know why the average user would even give a fudge
about the number...