Skip to content

Latest commit

 

History

History
71 lines (53 loc) · 2.6 KB

2016-12-01.md

File metadata and controls

71 lines (53 loc) · 2.6 KB
Raw

Version Management and Installers Discussion

Attendees

  • Corey Butler (@coreybutler)
  • Myles Borins (@thealphanerd)
  • Josh Gavant (@joshgav)
  • William Kapke (@williamkapke)
  • Mikeal Rogers (@mikeal)
  • Jeremiah Senkpiel (@fishrock123)
  • Troy Connor (@troy0820)

Next steps:

  • Document and come to consensus on default patterns, paths, etc.
  • Investigate cross-platform installer options like Electron.
  • Track usage of different installation methods on website, perhaps via a header.
  • Add a guide to the web site on available version managers and how they work.

What are the use cases for version managers?

  • Developer installing on a local machine, we don’t want to force them to the command line.
  • Developer who needs to switch environments for testing.
  • Assist with updates to runtime.

Installation is our most important use case, enable people to get started quickly from the web site home page.

Some systems have their own system package manager (apt, homebrew). But the package author would bypass any of our systems and use the raw tarballs.

Should we orient around the needs of the installer? What might that mean?

  • Would be best if the installer utilized the command-line/API packages.
  • Consider Electron installer?
    • Initial download is 136MB, but may be possible to trim.
    • Work has begun at nodejs/installer.
  • Are there alternatives?
    • bitRock
    • Qt?
    • Web page with config options which generates a script which can be run automatically.

Should we focus on a JS implementation?

  • Would encourage more contributors, but is that important?
  • nvm uses POSIX. Best part is that it doesn’t require JS or a Node runtime. But it doesn’t work on Win32 and it’s more difficult to modify.
  • Maybe we should focus on Windows independently anyway? JS code would also be full of “#ifdef”-like statements.

What about nvm being in the Foundation?

  • Should only projects actively supported by core be in Foundation?
  • Bring them all in? Not sustainable.
  • So if something is to be in core/Foundation, would need to be one, and would need to follow documented patterns and standards.
    • Should it be nvm? Maybe, still too early to tell. First come to consensus on standard patterns.

Why did we choose to do certain things in existing installers? E.g. /usr/local/bin on Linux, /Users/ on Windows. Perhaps ask @bnoordhius.