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 lifecycle policy
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
 
Boris Zbarsky  
View profile  
 More options Jun 22 2011, 11:10 pm
Newsgroups: mozilla.dev.planning
From: Boris Zbarsky <bzbar...@mit.edu>
Date: Wed, 22 Jun 2011 23:10:35 -0400
Local: Wed, Jun 22 2011 11:10 pm
Subject: Re: lifecycle policy
Print | View thread | Show original | Report this message | Find messages by this author
On 6/22/11 7:36 PM, Rick Alther wrote:

> However, I'm not a fan of 5.0 being a minor update to 4.0. Why not just
> label it 4.1.0 or something similar then? How are we supposed to know
> when a new release is a major update or not?

How are you defining "major update"?

> What happens if there is a change which changes
> the ABI/API significantly to break stuff (as a major version might)?

5.0 breaks ABI in various ways.  Binary addons that are compatible with
4.0 are not compatible with 5.0 without recompiling, generally.

> However, what about extensions not hosted on AMO,
> in particular, internal enterprise repositories?

Going forward, these would ideally use the Addon SDK and hence not have
compat issues at all, right?

> This new versioning policy really hinders enterprise uptake.

More precisely, the policy of actually adding features when they're
ready as opposed to lumping them all together into big-bang releases
hinders enterprise uptake, right?  That is, we could call this version
4.0.2, but since it has various incompatible changes (including various
new web-facing features) it's just as much of a problem for enterprises,
as I understand.

> With minor updates, it's not much of an issue because that implies nothing
> significant changed - just fixes and perhaps minor enhancements. Major
> releases require testing. Even though 5.0 is a minor update to 4.0

Defined how?  There are various changes that could break compatibility
with binary extensions, non-binary extensions, and intranet sites....

> Faster releases don't break the enterprise, but a
> versioning policy where you can't tell what's major and what's minor does.

The real problem for enterprise deployments is that in the new setup
there is no such distinction.  All updates will typically contain
substantive changes of some sort....

This was in fact considered.  The problem is that we feel that we don't
have the developer resources to effectively dedicate a separate team to
doing long-term support of old versions, which is what it sounds like
enterprises want.

If IBM (or any combination of companies interested in such a thing)
wants to help maintain long-term-support branches of Firefox for
enterprise use, I'm pretty certain that would be very welcome.

-Boris


 
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
©2013 Google