WebExtensions/GoFaster - Revision history

Amckay: /* Example timeline */

2016-02-25T20:55:05Z

Example timeline

← Older revision		Revision as of 20:55, 25 February 2016
Line 18:		Line 18:

	This is an example timeline, where in Firefox takes 6 weeks.		This is an example timeline, where in Firefox takes 6 weeks.


	<pre>		<pre>
	~~Coding Release cyle~~		+-------------------------------------+
	+~~------^-~~----------~~--^~~		Firefox \|Beta \|Stable \|
	+---------------------------+		+-------------------------------------+
	Firefox ~~\|Night \|Aurora~~\|Beta \|Stable\|
	+---------------------------+

	~~Code Rel.~~		+--------------------
	+--~~--^~~----^		Web Ext \|2.0 \|2.1 \|
	+--------------+		+-------------------------------------+
	~~Stable~~ \|~~Dev \|1~~.1b\|1.1 \|		\|3.0 \|3.1 \|2.0 \|2.1 \|
	~~Web Ext.~~ +--------------+		+-------------------------------------+
	+----------~~----+~~
	~~\|Dev \|1.2b\|1.2 \|~~
	+--------------+
	~~+--------------+~~
	\|~~Dev~~ \|1.3b\|1.3 \|
	+---------~~-----+~~
	+--------------+
	~~\|Dev \|1.4b\|1.4 \|~~
	+--------------+
	</pre>		</pre>

	In this example, development would be in a ~~four~~ week cycle~~, followed by a four week beta when testing~~ would ~~occur, followed by a release~~. ~~Meaning~~ that we would ~~ship around 4 versions of Firefox in one~~ release of ~~Firefox~~.		In this example, development would be in a three week cycle. Each Beta and Stable would get the newest version. But we could ship minor releases every three weeks. It implies that WebExtensions would mostly skip Aurora and we would cut a release of WebExtensions and land it on Beta.

	Those schedules are arbitrary but used as an example. It could be 3 weeks or 6 weeks.		Those schedules are arbitrary but used as an example. It could be 3 weeks or 6 weeks.

			'''Note:''' this was updated from the original which suggested 4 weeks, this one fits much more nicely.

	== native.js ==		== native.js ==

Amckay at 21:50, 18 February 2016

2016-02-18T21:50:53Z

← Older revision		Revision as of 21:50, 18 February 2016
Line 5:		Line 5:
	= Proposal =		= Proposal =

	WebExtensions moves into a system (or go faster) add-on.		WebExtensions moves into a [[Firefox/Go_Faster\|system (or go faster) add-on]].

	= Rationale =		= Rationale =

Amckay at 21:47, 18 February 2016

2016-02-18T21:47:58Z

← Older revision		Revision as of 21:47, 18 February 2016
Line 12:		Line 12:

	There's a good reason for that flow for many parts of Firefox, but it doesn't mean they need to apply to all parts of Firefox. In order to get WebExtensions out there as soon as possible and assist people with the upcoming deprecations, we need to get WebExtensions useful and relevant as soon as possible.		There's a good reason for that flow for many parts of Firefox, but it doesn't mean they need to apply to all parts of Firefox. In order to get WebExtensions out there as soon as possible and assist people with the upcoming deprecations, we need to get WebExtensions useful and relevant as soon as possible.

			= Details =

	== Example timeline ==		== Example timeline ==
Line 17:		Line 19:
	This is an example timeline, where in Firefox takes 6 weeks.		This is an example timeline, where in Firefox takes 6 weeks.

			<pre>
	Coding Release cyle		Coding Release cyle
	+------^-------------^		+------^-------------^
Line 37:		Line 40:
	\|Dev \|1.4b\|1.4 \|		\|Dev \|1.4b\|1.4 \|
	+--------------+		+--------------+
			</pre>

	In this example, development would be in a four week cycle, followed by a four week beta when testing would occur, followed by a release. Meaning that we would ship around 4 versions of Firefox in one release of Firefox.		In this example, development would be in a four week cycle, followed by a four week beta when testing would occur, followed by a release. Meaning that we would ship around 4 versions of Firefox in one release of Firefox.

Amckay: Created page with "'''Status: draft''' '''This is a draft, looking for feedback.''' = Proposal = WebExtensions moves into a system (or go faster) add-on. =..."

2016-02-18T21:43:52Z

Created page with "'''Status: <span style="color: orange">draft</span>''' '''This is a draft, looking for feedback.''' = Proposal = WebExtensions moves into a system (or go faster) add-on. =..."

New page

'''Status: <span style="color: orange">draft</span>'''

'''This is a draft, looking for feedback.'''

= Proposal =

WebExtensions moves into a system (or go faster) add-on.

= Rationale =

It's important to get WebExtensions out to developers, have them be used and be useful. There is a lead time between when we land the add-on API to when a developer can get around to implmenting an add-on based on it. As an example, anything landing past 2016-08-01, will not go to release until 2017.

There's a good reason for that flow for many parts of Firefox, but it doesn't mean they need to apply to all parts of Firefox. In order to get WebExtensions out there as soon as possible and assist people with the upcoming deprecations, we need to get WebExtensions useful and relevant as soon as possible.

== Example timeline ==

This is an example timeline, where in Firefox takes 6 weeks.

Coding Release cyle
+------^-------------^
+---------------------------+
Firefox |Night |Aurora|Beta |Stable|
+---------------------------+

Code Rel.
+----^----^
+--------------+
Stable |Dev |1.1b|1.1 |
Web Ext. +--------------+
+--------------+
|Dev |1.2b|1.2 |
+--------------+
+--------------+
|Dev |1.3b|1.3 |
+--------------+
+--------------+
|Dev |1.4b|1.4 |
+--------------+

In this example, development would be in a four week cycle, followed by a four week beta when testing would occur, followed by a release. Meaning that we would ship around 4 versions of Firefox in one release of Firefox.

Those schedules are arbitrary but used as an example. It could be 3 weeks or 6 weeks.

== native.js ==

There's been a proposal for running experiemental code in an add-on and shipping that out to users. This is very similar to this proposal and having a whole pile of API's living inside an add-on which users will install. https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457

If the stable core of WebExtensions is a system add-on, then you can install the native.js add-on over the top of the system add-on and it will override it. That means that each time we release a new stable core of WebExtensions, we'll also need to bump the native.js add-on and bundle all of stable inside native.js. It means that developers can install native.js to get all the experimental code.

This means we'll essentially be responsible for two add-ons, although only one of them could be active at a time.

== Project lifecycles ==

Projects go through various lifecycles, they have an initial phase where they need to get as many users as possible. That oftern means quicker cycles, faster feature implementations and faster bug fixes. Once a product has reached a level of maturity and stability it will move slower.

For comparison the SDK went through a similar life cycle. It started out as a library that was packaged into each add-on and then later moved into mozilla-central. The SDK team never had system add-ons available to them.

== The harder bits ==

=== Release cycles ===

Undefined at this point, but this needs to be a balance between risk and desire to push. The risk for add-ons causing breakages amongst other add-ons is low right now, but will increase as the add-on community builds out more add-ons. See early point about project lifecycles.

=== Testing ===

Currently this is a bit unknown for system add-ons. Ideally we want to be able to run our tests independently of mozilla-central, but be able to utilize the existing Firefox test infrastructure and test each release against all the versions of Firefox. Hello does this by pushing the code from github back into mozilla-central onto the fxteam branch and running the tests there.

=== Dependencies ===

There will be changes that cannot be done completely in the add-on. Some recent examples are webNavigation and webRequest where the underlying platform code need to be changed. This will require us to figure out in advance what requires platform changes and what does not and prioritize accordingly. Currently we are changing APIs to expose features the same as Chrome. This might not happen in the future once parity is reached and we are working on Firefox features.

=== Stabilizing ===

At some point in the future we can move this code back into the tree once we've reached a stable point. It doesn't mean we are on this train forever.

=== Reloading ===

When the system add-on gets installed and updates the APIs, we might need to reload all the add-ons. This is likely a similar problem for native.js

=== Addon Dependencies ===

Currently WebExtensions follow the existing Add-on dependency of specifying the version of Firefox. How that might work with system add-ons is something we'd need to explore.