Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
mozilla.dev.planning
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Firefox 3.1 becoming Firefox 3.5
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
eternalsword  
View profile  
 More options Mar 7 2009, 2:05 am
Newsgroups: mozilla.dev.planning
From: eternalsword <micah.b...@gmail.com>
Date: Fri, 6 Mar 2009 23:05:42 -0800 (PST)
Local: Sat, Mar 7 2009 2:05 am
Subject: Re: Firefox 3.1 becoming Firefox 3.5
Print | View thread | Show original | Report this message | Find messages by this author
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.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google