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
 |
Newsgroups: mozilla.dev.planning
From: Dave Townsend <dtowns...@mozilla.com>
Date: Sat, 07 Mar 2009 09:25:41 +0000
Local: Sat, Mar 7 2009 4:25 am
Subject: Re: Firefox 3.1 becoming Firefox 3.5
On 7/3/09 07:05, eternalsword wrote:
> The problem as I see it is that there is no consistent numbering We actually have very close to this already, except that your example of > 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. 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 Extension authors shouldn't have to worry about their maxVersion on > 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. 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 We could certainly get better at planning for sure, but of course > really a strong suit in Firefox development, even if it is well > documented. 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 Why would it be useful for planning purposes? Planned releases with > precisely for planning purposes, and not for some arbitrary > interpretation by an end-user. 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, Numbering is mostly arbitrary IMO. It is a subjective measurement of the > why not make it more beneficial for the extension developers, who are > responsible in large part for the popularity of firefox? 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. 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.
| |||||||||||||