Strawman alternative release schedule proposal.

[Zack Weinberg]

I'd like to throw out an alternative release schedule idea that kinda
splits the difference between what we have now and the ESR proposal.
This would be _instead of_ ESR as such.

1) We continue making releases approximately every six weeks.

2) Every fourth release (thus, approximately once every six months) we
do a "major" release. Changes that potentially break add-ons, and
visible changes to the UI, go ONLY in these releases, unless we have to
break compatibility or UX to address a security problem.

3) The other "minor" releases may make changes of any kind (in
particular, Web-compat hits are okay under the same criteria we use now
for deciding if those are acceptable) as long as they don't visibly
alter the UI or break add-on compatibility.

4) MoCo commits resources to provide security-and-stability patches for
release M.N for six additional months after release (M+1).0 happens.
This gives people who do not want to upgrade until an add-on is updated,
or dislike a UX change, a window where they can avoid the upgrade
without making themselves vulnerable.

4a) If third parties wish to continue backporting security-and-stability
fixes for older branches after MoCo discontinues them, they are free to
do so, and may make use of our infrastructure including release
machinery - however, they need to commit to some threshold of diligence
(e.g. will backport all critical+high security fixes that are relevant).
This covers the ESR use case. (We try to persuade e.g. Linux
distributors to step up here.)

5) The branch that will become the next major release exists at all
times. Breaking changes can therefore land at any time. Non-breaking
changes go first to the next-minor-release branch and are periodically
merged up. And it's an additional pre-Aurora release channel for the
curious and for people who have add-ons to fix.

5a) We *stop* landing breaking changes on that branch as soon as it's
"on deck" (in the baseball sense), giving add-on authors at least 18
weeks to fix their add-ons for any change. (The branch for the
*subsequent* major release must therefore be created at that point.)

i) We make side-by-side installation and use of browsers tracking more
than one release channel super easy and fully supported, dammit.

zw

[Doug Sherk]

I love this plan! There's a bit more overhead to this but it sounds more
reasonable to me to give extra time on major UI and API changes.

--
Doug

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

[L. David Baron]

On Friday 2011-09-23 11:15 -0700, Zack Weinberg wrote:
> 2) Every fourth release (thus, approximately once every six months)
> we do a "major" release. Changes that potentially break add-ons,
> and visible changes to the UI, go ONLY in these releases, unless we
> have to break compatibility or UX to address a security problem.

I think this covers most changes; thus your proposal requires that
most work land in one quarter of the time, which isn't practical.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Boris Zbarsky]

On 9/23/11 2:15 PM, Zack Weinberg wrote:
> 3) The other "minor" releases may make changes of any kind (in
> particular, Web-compat hits are okay under the same criteria we use now

Any Web-compat hit is ipso facto an addon compat hit....

-Boris

[Ron Hunter]

Might as well go back to once a year updates.
Competition manages to do this rapid update thing, and getting new
features, even if they change the UI, to users is the name of the game,
which in case you have forgotten is COMPETITION. Stick with 6 weeks.

[Asa Dotzler]

Zack Weinberg wrote:

> 2) Every fourth release (thus, approximately once every six months) we
> do a "major" release. Changes that potentially break add-ons, and
> visible changes to the UI, go ONLY in these releases, unless we have to
> break compatibility or UX to address a security problem.

From the Product side of things, I'm not OK with sacrificing the
flexibility for UI and features changes that the current 6 weeks cycle
gives us.

Changing UI twice a year means larger and more user-disrupting changes
rather than the more gradual accumulation of smaller tweaks and
improvements which may not disrupt users at all.

It also means not having the freedom to deliver a great new feature to
market for potentially 6 months. That's something our competition aren't
restricted on and one of the primary motivations for the faster release
cadence.

If we have to wait 6 months to deliver a great new feature, our
competitors will consistently beat us in shipping our own features (see
Opera's "opera menu" and Safari's "download panel" for examples) and we
will be right back where we started before the move to the faster cadence.

If this item 2) is a foundational requirement of your proposal,
something you don't think can be compromised, then, *IMO*, I don't think
this proposal can work for Firefox.

- A

[Joshua Cranmer]

On 9/23/2011 1:15 PM, Zack Weinberg wrote:

> 2) Every fourth release (thus, approximately once every six months) we
> do a "major" release. Changes that potentially break add-ons, and
> visible changes to the UI, go ONLY in these releases, unless we have
> to break compatibility or UX to address a security problem.

Since any API change could potentially break add-ons--where by API I
mean any IDL change, or the modification/deletion of any functions in
front-end code, you would be effectively, as I understand your proposal,
disallowing any major changes except for a narrow window of once every
six months. From my (admittedly, partially ignorant) standpoint, it
would be like returning to the pre-4.0 changes where the trunk was
effectively perpetually in beta feature-freeze.

[Asa Dotzler]

Zack Weinberg wrote:
> i) We make side-by-side installation and use of browsers tracking more
> than one release channel super easy and fully supported, dammit.

Yes. This is something I care a lot about. Unfortunately, we don't have
resources immediately available. If you can be that resource, or even
part of it, here is the proposal.
https://wiki.mozilla.org/Features/Desktop/Ability_to_run_concurrent_channels

- A

[Dao]

On 23.09.2011 20:25, Doug Sherk wrote:
> I love this plan! There's a bit more overhead to this but it sounds more
> reasonable to me to give extra time on major UI and API changes.

We have infinite time for major UI and API changes right now, as far as
the release process is concerned. What we need to be careful with is
landing half-baked stuff when a merge is around the corner.

dao

[Zack Weinberg]

On 2011-09-23 11:38 AM, L. David Baron wrote:
> On Friday 2011-09-23 11:15 -0700, Zack Weinberg wrote:
>> 2) Every fourth release (thus, approximately once every six months)
>> we do a "major" release. Changes that potentially break add-ons,
>> and visible changes to the UI, go ONLY in these releases, unless we
>> have to break compatibility or UX to address a security problem.
>
> I think this covers most changes; thus your proposal requires that
> most work land in one quarter of the time, which isn't practical.

(Several other people said essentially the same thing; I'm just going to
respond once, here.)

I could be wrong, but this seems unduly pessimistic. The overwhelming
majority of the work I did as a MoCo employee did not break add-on
compatibility or change the user experience. Here's an incomplete list
of things that (it seems to me) we could keep putting in minor releases:

* Improvements to existing Web features
* Entirely new Web features
* Speed improvements
* Aesthetic improvements (e.g. bug 19963)

* Additions to exposed extension-JS interfaces
* Entirely new exposed extension-JS interfaces

* New _optional_ UI elements (such as Panorama) and non-intrusive
improvements to the behavior of existing UI elements (like bug 678600).

The only things I can think of that we _couldn't_ do in a minor release
are break the duck type of an extension-JS interface, modify browser XUL
in a way that would break an <overlay> (this would probably break
visible UI anyway) and intrusive UI changes (like changing from the
traditional menu bar to the unified menu).

Note that I would accept changes in minor releases that require an IID
bump, as long as they don't change the duck type of that interface from
JS's perspective. But then, I think we should officially deprecate and
phase out support for binary add-ons anyway.

zw

[Zack Weinberg]

Could you elaborate, please? This doesn't make any sense to me. "Addon
compat hits" in my head are only the things I listed in my reply to dbaron.

zw

[azakai]

Addons can use web APIs to do things (and often do). For example an
addon could create a canvas element and do operations on that, then
render the result somewhere. Any changes to the HTML5 canvas element
could potentially break such an addon. As another example, addons can
use web workers for background processing. So any changes to the web
worker API can potentially break such an addon.

Of course normally changes to frozen web APIs are minor, because we
(and everyone else) don't want to break websites. So the risk here
might be fairly small. However, addons can use work-in-progress web
APIs (that are still prefixed, for example), as well as JS
enhancements that are still undergoing some amount of flux (typed
arrays, weak maps - no prefix there), and so forth, where the risk for
breaking changes can be high. The issue here is in part because addons
are written for a *single* browser, not for stable web standards, so
addons are more at risk of breakage than normal websites.

- azakai

[Steffen Wilberg]

> 3) The other "minor" releases may make changes of any kind (in
> particular, Web-compat hits are okay under the same criteria we use now
> for deciding if those are acceptable) as long as they don't visibly
> alter the UI or break add-on compatibility.

I think that would not be acceptable for "enterprise" because it has the
potential to break their intranet apps and thus would take some 6 months
or so of testing/verification/certification...
Isn't that why they want extended-support releases in the first place?

(I know security updates might break them as well, but it looks like the
risk/benefit ratio of those is deemed acceptable, especially if you wait
a week or two after their release.)

Steffen

[Boris Zbarsky]

On 9/24/11 12:40 PM, Zack Weinberg wrote:
> I could be wrong, but this seems unduly pessimistic. The overwhelming
> majority of the work I did as a MoCo employee did not break add-on
> compatibility or change the user experience. Here's an incomplete list
> of things that (it seems to me) we could keep putting in minor releases:
>
> * Improvements to existing Web features

Maybe. It depends on the improvement.

> * Entirely new Web features

No. This breaks addon compat. If the addon uses inline attribute event
handlers, you can't add new properties on Element, Document, Node,
without possibly causing name collisions. If it uses them on HTML
elements, you can't add properties on HTMLElement either.

> * Speed improvements

As long as they don't change APIs. Often they do. Or are you not
worrying about binary addons here? Note that binary addons are some of
the things causing grief for large deployments. Oh, and for users of
all the various virus scanner toolbars, etc. Was Google toolbar pure
JS, by the way?

> * Additions to exposed extension-JS interfaces
> * Entirely new exposed extension-JS interfaces

Why is this limited to JS? It certainly simplifies things, but ignores
where a lot of the addon compat pain is.

> The only things I can think of that we _couldn't_ do in a minor release
> are break the duck type of an extension-JS interface, modify browser XUL
> in a way that would break an <overlay> (this would probably break
> visible UI anyway) and intrusive UI changes (like changing from the
> traditional menu bar to the unified menu).

Or any removal of web-facing functionality. Or really any addition of
web-facing functionality.

Addons use web technologies. That's the selling point. It also means
that our web-facing API is part of our addon compat story.

Again, this is limiting to pure-JS addons, of course.

One other comment: even for pure-JS addons, ctypes exists. So that
makes all exported symbols part of our addon API. :(

> But then, I think we should officially deprecate and
> phase out support for binary add-ons anyway.

Sure. Once we get there, we can have a totally different conversation!

Of course the race is on between that and SDK-based addons.

-Boris

[Henri Sivonen]

On Sat, Sep 24, 2011 at 7:40 PM, Zack Weinberg <za...@panix.com> wrote:
> * Speed improvements

Extensions do things that are impossible from the Web and that our own
code is known not to do. This can have undesirable effects. For
example, I reasoned from the capabilities of the Web platform that we
don't need one fragment parser per document and a fragment parser per
process was enough. I made that change which made NoScript hang the
browser (because NoScript called Web APIs from an observer that fires
when it's not safe to call into Web APIs).

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Steve Fink]

On the face of it, that sounds to me like a great example of the
potential problems. But it also suggests to me that perhaps the best
solution is not to avoid (or revert) such changes, but rather that we
should use these as opportunities to identify the bits of functionality
that are useful and expose them in a way that is more general and
future-proof, and hopefully nicer to use. (For all I know, that's what
happened in this case. I don't know anything about that area.) Give
NoScript a straightforward way to do whatever it's doing, and if other
extensions break, suggest that they use the new API as well (or if
they're using it for something else that the new API doesn't support,
then consider their use case separately and decide whether we want to
support it or not.)

For all I know, though, perhaps per-document fragment parsers are
exactly the straightforward way to handle the NoScript use case. I think
my general point stands, regardless.

[Zack Weinberg]

On 2011-09-25 10:38 PM, Boris Zbarsky wrote:
> On 9/24/11 12:40 PM, Zack Weinberg wrote:
>> * Entirely new Web features
>
> No. This breaks addon compat. If the addon uses inline attribute event
> handlers, you can't add new properties on Element, Document, Node,
> without possibly causing name collisions. If it uses them on HTML
> elements, you can't add properties on HTMLElement either.

[etc]

I really appreciate this detailed explanation of where I'd gone wrong.

It seems like my original proposal is a non-starter *at present*, but I
would appreciate thoughts on whether you (collectively) think it's worth
trying to aim for being able to do something like it in the future. I
see a lot of pain in the add-on community right now, and I think we're
in a bad way if we can't do *anything* to help... (even if that winds
up being "see here are concrete ways in which this will not be so
horrible in a year or so").

>> But then, I think we should officially deprecate and
>> phase out support for binary add-ons anyway.
>
> Sure. Once we get there, we can have a totally different conversation!
> Of course the race is on between that and SDK-based addons.

Do we have any internal assessment of what people are using binary
add-on components *for*? If we are going to try to phase them out, we
need an exit strategy for the people using them (and "just use jsctypes"
isn't really enough there).

zw

[Boris Zbarsky]

On 9/26/11 4:03 PM, Zack Weinberg wrote:
> It seems like my original proposal is a non-starter *at present*, but I
> would appreciate thoughts on whether you (collectively) think it's worth
> trying to aim for being able to do something like it in the future. I
> see a lot of pain in the add-on community right now, and I think we're
> in a bad way if we can't do *anything* to help... (even if that winds up
> being "see here are concrete ways in which this will not be so horrible
> in a year or so").

I do think that addons that follow good practices for touching the DOM
and use the SDK should be in a pretty good place compat-wise....

> Do we have any internal assessment of what people are using binary
> add-on components *for*?

Some are using it to make their poorly structured code run faster (e.g.
skype).

Some are using it to access platform C++-only bits (malware, antivirus
vendors, etc).

Some are using it to talk to binary blobs they include in the addon
(this really is "just use jsctypes").

I don't have any data on relative frequencies myself...

-Boris

[Schalk Neethling]

Talking about add-ons, and this may not be the best place to bring it
up, or maybe it is but, I am curios as to why there are so many add-ons
written for Chrome and Firefox seems to lag way behind.

I must admit I have not written many, maybe one for each, but is there
something specific that makes writing add-ons for Firefox that much more
of a challenge?

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

--
Kind Regards,
Schalk Neethling
Web Developer
Mozilla Corporation

[beltzner]

You're right, this isn't the right place for that sort of question.

cheers,
mike (moderator)

On Oct 12, 2011 3:05 PM, "Schalk Neethling" <sneet...@mozilla.com> wrote:

> Talking about add-ons, and this may not be the best place to bring it up,
> or maybe it is but, I am curios as to why there are so many add-ons written
> for Chrome and Firefox seems to lag way behind.
>
> I must admit I have not written many, maybe one for each, but is there
> something specific that makes writing add-ons for Firefox that much more of
> a challenge?
>
> On 2011/10/12 08:31 PM, Boris Zbarsky wrote:
>

>> ______________________________**_________________
>> dev-planning mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>

>>
>
> --
> Kind Regards,
> Schalk Neethling
> Web Developer
> Mozilla Corporation

> ______________________________**_________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>