Installing canary and the normal version alongside eachother

It's rather standard to be able to install the release-version, and future-version, of web technologies side-by-side: Chrome Canary, FireFox Nightly, WebKit Nightly, etc.

In looking to report a flashing-URL bug, I wanted to ascertain whether it's specific to the Canary version I'm using (2.0.4), or the if it exists in the release version (1.4.8) as well — but I realised it'd be a huge pain-in-the-ass to downgrade.

This is something of a problem, though: the two versions may require slightly different configurations … and, unfortunately, the current architecture requires the release-channel to be documented in the configuration file. Oops.

Here's, tentatively, one way that I see this working, without revisiting the config.updateChannel behaviour that was just established:

1. The configuration dot-file (~/.hyper.js) should default to checking for channel-specific versions first, based on the currently-being-initialized version of the app (i.e. if ‘stable’ is being booted, it reads from ~/.hyper.js; but if ‘canary’ is, it checks for ~/.hyper.canary.js first, before falling-back to ~/.hyper.js.)
2. The dot-directory used by Hyper should always correspond to the currently-being-initialized version — i.e. the above, but with no fallback: ‘stable’ uses ~/.hyper_plugins/, while ‘canary’ uses ~/.hyper_plugins.canary/, creating it if it does not exist.

This leaves ‘upgrading’ rather complex, currently, though: you'd have to first change ~/.hyper.js to ‘canary’ … launch Hyper.app, let it update … move the current release to Hyper Canary.app, and your config to ~/.hyper.config.js … re-download Hyper.app … copy your configuration back to ~/.hyper.js … and change that release-channel back to ‘stable.’

Yeah. Gross.

Ideally, I think, to improve the install, upgrade, and configuration experience, it'd be ideal if this were consolidated; and the update-channel were not a factor of configuration, but of the installation:

1. We could change the update-channel to be hard-coded into the installation, and not the config-file,
2. then add a web-page / UI / menu-item / hpm (or similar) command, that distributes or manages installed versions of Hyper,
3. with each thus-installed version of Hyper following the above-described fallback behaviour for configuration.

I hope this Issue is welcome; and this obviously isn't a high-priority concern, but it's something to think about and plan for, as Hyper gains in popularity, and we gain more plugins or themes (and plugin- or theme-developers) who need to test their work in the future releases, or report bugs in Hyper itself.

Thanks for reading!

Start by mapping the existing update-channel configuration, application installation, and plugin-directory entry points; the issue identifies ~/.hyper.js, ~/.hyper_plugins/, and a possible hpm or UI command as relevant surfaces. Define the supported side-by-side installation and configuration behavior before selecting an implementation. Done means stable and canary versions can be installed and upgraded independently without manual configuration migration.