We need to: - find the right name for this new addon - build the addon (from this branch https://github.com/mozilla/r2d2b2g/pull/756) one xpi per platform - host it on AMO or elsewhere

About the name, I tend to think we should keep a similator name to the existing addon. Firefox OS Simulator sounds like a good description for this addon. But it will also be hard to communicate by having two addons with the same name... Also, one important detail is that we will spawn multiple simulator addons in the future. At least, one per branch, with one new addon id, so that you can install multiple simulator addons in the same firefox instance. For example simulator 1.2 and simulator 1.3. Finally, about the hosting. For FF26, we won't have time to integrate addon download and install in the app manager. We are going to just open a webpage that will allow install the addon. In such scenario, hosting on AMO looks like the best choice in order to avoid any scary popup about the addon being unsafe. The AMO page will also help describing the addon in detail and help us keeping a short first run landing page.

Any opinion on names before we end up naming this addon applicator simulator companion? See also bug 915261 for adb addon story.

I'm partial to using 'runtime' instead of 'simulator', eg we would release different packages like: * Firefox OS Runtime 1.2 (OS X) * Firefox OS Runtime 1.4 (Win32) This differentiates from the previous add-on and emphasizes that the extension is something you plug into Firefox to add a capability, not a standalone thing. needinfo'ing Myk & Paul for their perspectives.

Runtime sounds like a nice choice to me.

"Firefox OS Runtime" vs "Firefox OS Simulator". We used Simulator before. It worked. And today it's still the simulator without the dashboard. Runtime sounds too generic. Simulator sounds pretty straight forward to me. What I see coming is this kind of discussion: - "something something Firefox OS Runtime something something" - "what is Firefox OS Runtime?" - "it's a simulator" - "ah" I'd say: let's not change something that works.

Won't it be confusing to have two addons both called the Simulator, one of which is the older Simulator with its dashboard, and the other is dashboard-less, meant for the App Manager? It seems strange, since I am guessing they will both live on AMO at the same time. Won't people pick the wrong one and be confused?

(In reply to J. Ryan Stinnett [:jryans] from comment #6) > Won't it be confusing to have two addons both called the Simulator, one of > which is the older Simulator with its dashboard, and the other is > dashboard-less, meant for the App Manager? > > It seems strange, since I am guessing they will both live on AMO at the same > time. Won't people pick the wrong one and be confused? There will be only one Simulator. If the user uses Firefox 26+, it will get the version of the Simulator that is dashboard-less.

(In reply to Paul Rouget [:paul] from comment #7) > (In reply to J. Ryan Stinnett [:jryans] from comment #6) > > Won't it be confusing to have two addons both called the Simulator, one of > > which is the older Simulator with its dashboard, and the other is > > dashboard-less, meant for the App Manager? > > > > It seems strange, since I am guessing they will both live on AMO at the same > > time. Won't people pick the wrong one and be confused? > > There will be only one Simulator. If the user uses Firefox 26+, it will get > the version of the Simulator that is dashboard-less. I guess that is not what it sounded it like in comment #1, when Alex said "it will also be hard to communicate by having two addons with the same name". Why does he think there will be two addons then?

(In reply to Paul Rouget [:paul] from comment #7) > There will be only one Simulator. If the user uses Firefox 26+, it will get > the version of the Simulator that is dashboard-less. Would we use the same guid? This would be a mess for people who use the same profile with Aurora and Nightly ( I'm guilty of this ). I guess I'm okay with Simulator as long as we message properly: * through blog posts and documentation * through a first-run experience on upgrade from Simulator 4/5 to App manager + 'new Simulator'

(In reply to J. Ryan Stinnett [:jryans] from comment #8) > There will be only one Simulator. If the user uses Firefox 26+, it will get > the version of the Simulator that is dashboard-less. It just occurred to me that this means we *have to* use thew same add-on guid, so we prevent a situation where the user has two different add-ons called 'Simulator'.

Runtime sounds good to me, I prefer having a different name than mislead people. We are already known for our funky name story [persona, browserid, ...], I would like not to be part of the next one. (In reply to Jeff Griffiths (:canuckistani) from comment #9) > Would we use the same guid? This would be a mess for people who use the same > profile with Aurora and Nightly ( I'm guilty of this ). We don't necessary need a different id between the dashboard-enable and the dashboard-less versions, *but* we need distinct ids between 1.2 and 1.3 and all possible variants of the runtime we come up with! (In reply to J. Ryan Stinnett [:jryans] from comment #8) > (In reply to Paul Rouget [:paul] from comment #7) > > There will be only one Simulator. If the user uses Firefox 26+, it will get > > the version of the Simulator that is dashboard-less. That's true just because of the compatiblity ranges of the addons. Dashboard-enable will be compatible up to 25 while the dashboard-less will start with 26. > > I guess that is not what it sounded it like in comment #1, when Alex said > "it will also be hard to communicate by having two addons with the same > name". Why does he think there will be two addons then? We will keep these two addons until FF25 is deprecated and we implemented all features of the dashboard to the app manager, like receipts. But I agree with paul, in a give firefox instance we shouldn't be able to install both. That being said that's not the main issue, even if compatiblity ranges helps a bit, it doesn't help understand what is going on when you have two distinct addons with the exact same name :o And I'm not sure AMO allows such thing.

Also while speaking about names, I often heard people talking about emulator when refering to the simulator. So I'm not sure simulator is a de-facto usual name for such product. Even if I agree that's not an emulator and simulator better highlight the subtle difference the simulator has over a real emulator, I think most app developers don't care about such level of detail.

(In reply to Alexandre Poirot (:ochameau) from comment #11) > Runtime sounds good to me, I prefer having a different name than mislead > people. We are already known for our funky name story [persona, browserid, > ...], I would like not to be part of the next one. Well, "persona" becoming "light theme" was weird. People keep referencing "light theme" as "persona" (I do). Same think with "jetpack" becoming "Addon SDK". I don't want "Simulator" to become "Runtime" just because its dashboard is merged in the app manager. But I'll leave this decision to Alex and Myk. If we can know the final name before Friday night, that'd be great (I use the word "simulator" in different places in the UI).

(In reply to Alexandre Poirot (:ochameau) from comment #12) > Also while speaking about names, I often heard people talking about emulator > when refering to the simulator. So I'm not sure simulator is a de-facto > usual name for such product. Even if I agree that's not an emulator and > simulator better highlight the subtle difference the simulator has over a > real emulator, I think most app developers don't care about such level of > detail. I believe we very intentionally chose 'Simulator' over 'Emulator' because the latter implies hardware / cpu emulation ( a la the android arm emulator ) whereas our offering is much more like iOS, in which the simulated OS runs native x86 using the full hardware cpu.

We've built a lot of brand recognition around the current name, and I'm wary of squandering it. We'll have multiple versions of the product available simultaneously, one per supported Firefox OS branch, and they'll need to have different IDs and distribution links/pages, so users can install them discretely. We can change the name of the classic addon. The classic addon and the modern addon will deliver similar simulations, even though the latter doesn't have a Dashboard. We don't have to distinguish the packages by platform, because we can automatically choose the appropriate version of the Simulator to install on a given user's computer (whether or not we distribute on AMO). So I think we should stick with the "Simulator" moniker but rename the classic addon to Firefox OS 1.1 Simulator and name each modern addon after the version of FxOS it simulates: * Firefox OS 1.1 Simulator (the classic addon, with Dashboard, available for Fx 23-25) * Firefox OS 1.2 Simulator (the modern addon, without Dashboard, available for Fx 26+) * Firefox OS 1.3 Simulator * Firefox OS 2.0 Simulator * etc.

I find myself curiously drawn to branding Fx OS Simulator 5 as 'Simulator Classic', but your suggestions make more sense.

The App Manager will open this link: - https://developer.mozilla.org/docs/Tools/Firefox_OS_Simulator#Installing_the_Simulator We will only need to add the final link to the addon there (on MDN).

We changed the URL: https://developer.mozilla.org/docs/Mozilla/Firefox_OS/Using_the_App_Manager#Simulator

Ok I like the 1.x proposal. Let's go with this. I started asking jorgev how to use mozilla account on AMO, the process is to start a personal project and then register mozilla account as an owner. So I'll try to upload xpis tomorrow to AMO with the name "Firefox OS Simulator 1.2", while keeping install.rdf named "Firefox OS Simulator" as John-Galt warned me that, otherwise, it would have been named "Firefox Os Simualator 1.2 1.2" in the addon manager... myk, could you start renaming the existing addon to 1.1?

(In reply to Jeff Griffiths (:canuckistani) from comment #16) > I find myself curiously drawn to branding Fx OS Simulator 5 as 'Simulator > Classic', but your suggestions make more sense. I like that "Classic" more clearly indicates there are additional differences between it and the newer distributions of the Simulator. Nevertheless, it would still be useful to identify the version of FxOS in the classic distribution, and "Firefox OS 1.1 Simulator Classic" is quite unwieldy, so it seems better to sacrifice some descriptiveness in the name and make up for it in the description. Thus I would call it either "Firefox OS 1.1 Simulator" or "Firefox OS Simulator Classic", which are both reasonable, so I don't have a strong preference and am open to suggestion. (In reply to Alexandre Poirot (:ochameau) from comment #19) > Ok I like the 1.x proposal. Let's go with this. > > I started asking jorgev how to use mozilla account on AMO, > the process is to start a personal project and then register mozilla account > as an owner. > So I'll try to upload xpis tomorrow to AMO with the name "Firefox OS > Simulator 1.2", while keeping install.rdf named "Firefox OS Simulator" as > John-Galt warned me that, otherwise, it would have been named "Firefox Os > Simualator 1.2 1.2" in the addon manager... > > myk, could you start renaming the existing addon to 1.1? Yes, but it sounds like we're conflating the addon's name with its version and the version of FxOS it includes. The existing addon is called "Firefox OS Simulator", and its current stable version is 4.0, which AMO and Add-ons Manager display as "Firefox OS Simulator 4.0", although they both distinguish the name from the version (Add-ons Manager by putting some space between them; AMO by making the version smaller and grey). I proposed renaming the old addon to "Firefox OS 1.1 Simulator", not "Firefox OS Simulator 1.1", and I didn't propose changing its version to 1.1, which I don't think we can do, since users wouldn't get prompted to update from 4.0 to 1.1, as Firefox/AMO would consider 1.1 to be older than 4.0. As for the new addon, I proposed calling it "Firefox OS 1.2 Simulator", not "Firefox OS Simulator 1.2", and I don't think we should use the version of FxOS as the version of the addon, because we will ship multiple builds of the addon for a given FxOS version, and each build should have a distinct version so Fx/AMO can auto-update them and we can distinguish them from each other when diagnosing user problems. I see three possibilities for the version string: 1. the version of the addon code, f.e. "6.0" to indicate the sixth major revision of that code (which we may use to produce builds for multiple versions of FxOS); 2. the date FxOS code was pulled to produce the build, f.e. "20130916" to indicate code pulled on 2013 September 16; 3. a combination of those values, f.e. "6.0.20130916". Of those, my initial impulse is to employ the last option, as it allows us to increment the version string when either the addon or FxOS changes. Then the new version of the addon would be displayed as "Firefox OS 1.2 Simulator 6.0.20130916". Which is still a substantial string, but it fits into the Add-ons Manager and AMO at any reasonable desktop screen resolution, and those interfaces do a fine job of emphasizing the name over the version, so I think it's ok.

myk built some xpi yesterday, we still have bad product name displayed in the app manager buttons, but that shouldn't prevent us from releasing the first xpi's. Unfortunately the amo upload tool rejects these xpis because this tool is unable to extract jars being shipped in the b2g... So I went ahead and published myk's links on ftp.mozilla.org in the MDN page: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Using_the_App_Manager#Simulator Windows: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/fxos_1_2_simulator-6.0pre1-windows.xpi Mac: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/fxos_1_2_simulator-6.0pre1-mac.xpi Linux: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/fxos_1_2_simulator-6.0pre1-linux.xpi

Kris can help get these posted on AMO, although in the long term we'll need a better solution than to enlist his help every time we update this addon (and the others).

(In reply to Myk Melez [:myk] [@mykmelez] from comment #22) > Kris can help get these posted on AMO, although in the long term we'll need > a better solution than to enlist his help every time we update this addon > (and the others). Erm, or rather: Kris *may* be able to help, so I have cc:ed him. Sorry, Kris, I didn't mean to speak on your behalf. But if it's available, your assistance would be very helpful!

My main issue being that I can't even create a new AMO entry because I'm stuck in this very first upload screen.

I can upload these... but having different add-ons for each FxOS version is going to create a lot of overhead. I'd much prefer one add-on that's able to fetch multiple versions of the runtime if that's at all doable.

Here is a new set of builds kindly provided by myk! Windows: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/fxos_1_2_simulator-6.0pre2-windows.xpi Mac: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/fxos_1_2_simulator-6.0pre2-mac.xpi Linux: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/fxos_1_2_simulator-6.0pre2-linux.xpi This includes a bunch of various fixes and also use latest 1.2 versions of gecko and gaia. These builds are good candidates for the first xpi being uploaded to AMO. Kris, could you create a new AMO entry for these xpi? We would need an addon called "Firefox OS 1.2 Simulator". Its version is going to be 6.0pre2xxxx. Please ping me on irc (ochameau) if you need anything. Regarding versions, we really need one addon per Firefox OS release. That's a key feature as it will allow developers to install multiple version of Fx OS and test their app on them. Keep it mind that Fx OS is now following rapid release cycle, but with longer timeframe than firefox desktop. So we will have less releases and not that many addons. Also addons will be deprecated over time, like what is going to happen with the existing simulator addon. The current Firefox OS Simulator addon will be deprecated with the release of Firefox 26 and also renamed to Firefox OS 1.1 Simulator. We are still using addons to ship Fx OS binaries as it is the easiest way to ship them and get them automatically updated. We have thought multiple times about doing that with its own specific mechanism, but that requires a bunch of work to be done correctly and disallow anyone to easily build and distribute its own simulation flavor. (for example: telefonica/zte specific builds...)

Kris, If you think this story won't scale on AMO, I'll host these addons on ftp.mozilla and get them updated from here tomorrow.

It depends on what you mean by scale. Having to review multiple add-ons every time the simulator base is updated is going to slow things down considerably. I also think, from a user experience perspective, it makes more sense to have the add-on itself manage the runtimes rather than packaging them into separate add-ons. I don't think this should in any way preclude users from installing multiple versions of the runtime. In any case, that's another discussion. I'll upload these builds, but I still consider it the wrong approach.

I uploaded the files. There as already an incomplete listing created for the add-on ID, with a prerelease version that I deleted: https://addons.mozilla.org/developers/addon/firefox-os-1-2-simulator/edit

Here is some tweaks for uploading xpis to a ftp: https://github.com/mozilla/r2d2b2g/pull/840 And somes xpis and update.rdf to ensure that xpis can really get updated: https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/1.2/ Tested and verified on three platforms and it seems to actually work! But I miss the locales building so xpis aren't perfect, so I'd really like to get myk feedback before releasing a ftp-updatable 6.0pre3 version.

So, I should have followed existing notes about releasing the addon: https://github.com/mozilla/r2d2b2g/wiki/Build-Process The main differences should be to replace "make package" by "make production". And then instead of renaming and scp-ing the file manually, we just do: FTP_USER=ldap-id "make release" And we should also update symbolic link rules. Otherwise, I choosed to create one directory per simulator addon, so one for 1.2, and we will most likely spawn another one for 1.3 soon. Then one folder by platform. Given that we are no longer hosting on AMO, we should be able to create linux32 and linux64 versions, right?

(In reply to Alexandre Poirot (:ochameau) from comment #31) > Given that we are no longer hosting on AMO, we should be able > to create linux32 and linux64 versions, right? Is it hard to do? --- Also, we'll need a landing page, right? Do we do that on MDN? How will the update mechanism work? Will we get a warning because the addon is not hosted on AMO?

(In reply to Alexandre Poirot (:ochameau) from comment #30) > Tested and verified on three platforms and it seems to actually work! > But I miss the locales building so xpis aren't perfect, so I'd really like > to get myk feedback before releasing a ftp-updatable 6.0pre3 version. I gave you some feedback in the pull request, which I also merged! And you found the Build Process doc, so you probably already know about building locales, but for reference, you just need to |make locales| to pull/update the locale repositories and set LOCALES_FILE while making *locales* and *build* (which we should probably do by default): LOCALES_FILE=${PWD}/build/languages.json make locales LOCALES_FILE=${PWD}/build/languages.json make build (In reply to Alexandre Poirot (:ochameau) from comment #31) > Otherwise, I choosed to create one directory per simulator addon, so one for > 1.2, and we will most likely spawn another one for 1.3 soon. Then one folder > by platform. Given that we are no longer hosting on AMO, we should be able > to create linux32 and linux64 versions, right? Right! The Linux combo pack was just a workaround for a limitation of AMO, and we don't need to do it if we distribute on FTP. (In reply to Paul Rouget [:paul] from comment #32) > (In reply to Alexandre Poirot (:ochameau) from comment #31) > > Given that we are no longer hosting on AMO, we should be able > > to create linux32 and linux64 versions, right? > > Is it hard to do? No, it's trivial! In fact, it's easier than creating the combo pack. > Also, we'll need a landing page, right? Do we do that on MDN? Yes, we'll want some page that points users directly to the appropriate build. MDN is ok for that, except that it probably doesn't let us run code, so we can't sniff the user's OS and point them directly at the right build: Download Firefox OS 1.2 Simulator for [Your Platform] And instead we have to list the builds and make them click the right link: Download Firefox OS 1.2 Simulator for: * Windows * Mac OS X * Linux 32-bit * Linux 64-bit > How will the update mechanism work? The Add-on SDK supports generating and publishing the update.rdf files that Firefox consumes to automatically update an addon. ochameau's build system enhancements include a build step that uses that feature, so each time we |make production| and |make release|, Firefox will automatically update users of older versions of the addon to the new one. > Will we get a warning because the addon is not hosted on AMO? Yes, but not because it isn't hosted on AMO but rather because it isn't linked from AMO. Users will get a download-time doorhanger asking them to allow the linking site (f.e. MDN) to install an addon. Plus the standard install-time dialog asking them to confirm installation (which happens for AMO-hosted addons as well). After installation, users will not have to confirm updates, so the download-time doorhanger is a one-time additional UX hit. And mossop (cc:ed) suggests there are ways around it.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #33) > > Will we get a warning because the addon is not hosted on AMO? > > Yes, but not because it isn't hosted on AMO but rather because it isn't > linked from AMO. Users will get a download-time doorhanger asking them to > allow the linking site (f.e. MDN) to install an addon. Plus the standard > install-time dialog asking them to confirm installation (which happens for > AMO-hosted addons as well). After installation, users will not have to > confirm updates, so the download-time doorhanger is a one-time additional UX > hit. And mossop (cc:ed) suggests there are ways around it. There were easy ways around it but apparently with a recent AMO rewrite they were dropped. We'll have to put up with the warning for now.

Paul mentioned he was thinking of doing a screencast about device setup. It might make sense to have this be a screencast of 'getting everything installed and running' - including the warning dialogs and some comment on how this isn't a big deal, the extensions are hosted on mozilla's ftp.

Could we use these URLs: https://ftp.mozilla.org/pub/mozilla.org/labs/simulator/1.2/ https://ftp.mozilla.org/pub/mozilla.org/labs/simulator/1.3/ https://ftp.mozilla.org/pub/mozilla.org/labs/simulator/adb-helper/

Simulator builds are now ready on ftp: https://ftp.mozilla.org/pub/mozilla.org/labs/fxos-simulator/1.2/ Note to anyone who already fetched xpis from the ftp before this message, you may have download one of my test addon I used to check xpi update... I suggest you to reinstall the addon and ensure that you do not fetch a cached xpi.