Skip to content

doc: add notes from collab summit discussion #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 2, 2016
Merged

doc: add notes from collab summit discussion #11

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
da7ea2d
doc: add notes from collab summit discussion
joshgav Dec 1, 2016
71ece93
Added additional attendees
coreybutler Dec 2, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions meetings/2016-12-01.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
## Version Management and Installers Discussion

* Date: 2016-12-01 (Collaboration Summit - Austin)
* GitHub issue: <https://github.com/nodejs/version-management/issues/5>
* Minutes: <https://docs.google.com/document/d/1UDDnHrmuVdG-ih3-Q8m5hbCfE7z7IuaVoB0keMC9as4>

## Attendees

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

**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](https://github.com/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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NVS is a cross-platform JS version-manager that is not full of "#ifdef"-like statements. While there certainly are some platform-specific sections of code, the great majority of the implementation can be cross-platform, thanks to the cross-platform APIs provided by the Node.js core modules.

Another significant consideration not listed here is that two separately-developed tools are unlikely to provide consistent functionality and user experience across platforms.


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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why only one? This makes no sense to me. Bringing in two, or three, in no way is a slippery slope to "all".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb the key new understanding we reached in our discussion Thursday was that any project in the Foundation needs to be actively supported by the Foundation. That means at least engineers maintaining and updating it, but more than that indicates some degree of assumed responsibility for us here in core; perhaps to address bugs and security issues, perhaps something else. /cc @mikeal @rvagg for further thoughts.

Based on that understanding it's probably not sustainable to support more than one in core, so we want to be conscientious about what that one is.

Does that help explain why it seems "only one in the Foundation" might be our goal? Do you think we could support more?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be best to continue this discussion here: nodejs/TSC#96 (comment). Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commented there, thanks.

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/<user> on Windows. Perhaps ask @bnoordhius.