Firefox 3.1 becoming Firefox 3.5
Mike Shaver
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
John J Barton
> 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
Dave Townsend
> 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
John J Barton
...
> 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
Shawn Wilsher
> 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.
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
Mike Shaver
<johnj...@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
John J Barton
> 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
John J Barton
>> 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.
>
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
Dave Townsend
>>> 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?
Shawn Wilsher
>> 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;
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
Sheppy
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/
John J Barton
> 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
eternalsword
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.
Kevin Brosnan
> 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.
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.
Philip Chee
> 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 <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.
Dave Townsend
> 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.
Dao
> [...] 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
> 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.
John Vivirito
>> 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.
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.
--
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
Mike Shaver
<mozilla.ext...@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
mozil...@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.*.
Gordon P. Hemsley
> >> 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
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 == [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.
Samuel Sidler
> 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
Gordon P. Hemsley
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
Dave Townsend
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.
John Vivirito
> On Sat, Mar 7, 2009 at 9:20 AM, John Vivirito
> <mozilla.ext...@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:
>
> 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.
>
> it won't be a number that sorts lower than 3.5, I assure you. :)
>
> Mike
>
>
> 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.*.
>
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?
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.
In the case of Ubuntu we don't auto-update and I'm sure is same for most
Linux distributions
timeless
> 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.
mozil...@gmail.com
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
Thomas Stache
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?
John Vivirito
> dev-planning mailing list
> dev-pl...@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.
Henrik Skupin
> 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
John Vivirito
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
>
bth...@gmail.com
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.
Robert Kaiser
> 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’s 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
decision? Either it's a good product or it's not, either you like it or
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
decision, and so far the Firefox marketing people have done a very good
job to bring a product with the Mozilla philosophy to a rapidly
increasing number of people. Don't you trust them? If you do, could you
stop whining?
Robert Kaiser
P.S.: Jumping to X.5 for such steps is a long-going tradition, dating
back to the times when Mozilla still was only a codename for Netscape's
browsers.
Daniel Holbert
> this is, quite honestly, pointless talk - and i say this as a user.
> 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