Firefox 3.1 becoming Firefox 3.5

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Firefox 3.1 becoming Firefox 3.5

Mike Shaver
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

John J Barton
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Dave Townsend
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

John J Barton
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Shawn Wilsher-3
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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Mike Shaver
In reply to this post by John J Barton
On Fri, Mar 6, 2009 at 2:29 PM, John J Barton
<[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

John J Barton
In reply to this post by John J Barton
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

John J Barton
In reply to this post by John J Barton
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Dave Townsend
In reply to this post by John J Barton
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?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Shawn Wilsher-3
In reply to this post by 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?

> 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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Sheppy
In reply to this post by John J Barton
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/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

John J Barton
In reply to this post by John J Barton
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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

eternalsword
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Kevin Brosnan
On Sat, Mar 7, 2009 at 02:05, eternalsword <[hidden email]> 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.

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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Philip Chee
In reply to this post by John J Barton
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 <[hidden email]>, <[hidden email]>
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.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Dave Townsend
In reply to this post by eternalsword
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Dao-6
In reply to this post by eternalsword
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

John Vivirito-3
In reply to this post by Dave Townsend
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.
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.

--
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



_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

Mike Shaver
On Sat, Mar 7, 2009 at 9:20 AM, John Vivirito
<[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox 3.1 becoming Firefox 3.5

mozillacat
In reply to this post by Dave Townsend
On Mar 7, 9:20 am, John Vivirito <[hidden email]>
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.*.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12