Merge pull request #1435 from krwq/installation-scenarios
Add/update installation scenarios
This commit is contained in:
Piotr Puszkiewicz
commit
4a97d540c8
2 changed files with 72 additions and 92 deletions
|
|
@ -1,92 +0,0 @@
|
|||
Beta install options and experience
|
||||
===================================
|
||||
|
||||
For the Beta timeframe, we will have two main install/acquisition experiences:
|
||||
|
||||
1. Native/package installers
|
||||
2. Local install
|
||||
|
||||
## Native/package installers
|
||||
|
||||
Native/package installers refers to the pre-packaged installers that are using whatever technology is "native" to the targeted platform. These installers are meant to be used mostly for setting up a development environment one one's computer for writing applications, trying out the CLI tooling etc. Their benefit is that they install all of the pre-requisites for the CLI tooling to work. Their downside is that they install a machine-wide copy of the CLI tooling and they require (with the sole exception of the Homebrew package) super-user privileges.
|
||||
|
||||
For Beta in January timeframe, we will have these native installers:
|
||||
|
||||
* Windows
|
||||
* [MSI installer](https://dotnetcli.blob.core.windows.net/dotnet/dev/Installers/Latest/dotnet-win-x64.latest.msi)
|
||||
* Ubuntu
|
||||
* Debian package through a custom apt-get feed
|
||||
* OS X
|
||||
* [PKG installer](https://dotnetcli.blob.core.windows.net/dotnet/dev/Installers/Latest/dotnet-osx-x64.latest.pkg)
|
||||
* Homebrew formula - TBD
|
||||
* CentOS
|
||||
* N/A
|
||||
|
||||
Instructions on how to get and use these above installers can be found on http://dotnet.github.io/getting-started/.
|
||||
|
||||
>**Note:** as of time of this writing (12/21/2015) the Homebrew formula is still being made.
|
||||
|
||||
## Local install
|
||||
|
||||
Local install refers to a zip/tarball that the user would need to download and then copy over to a location on disk where the tools should live. This way of installing has the benefit of providing complete control over the location of the CLI tooling, allowing multiple versions to live side-by-side as well as not requiring super-user privileges. The downside is that all of the dependencies need to be installed manually. The main scenario for using this is to avoid machine-wide installs, or in those scenarios where the CLI tools should "follow" the source (i.e. source code repos, build servers etc.)
|
||||
|
||||
There are two main ways
|
||||
|
||||
* ZIP file for [Windows](https://dotnetcli.blob.core.windows.net/dotnet/dev/Installers/Latest/dotnet-win-x64.latest.msi)
|
||||
* Tarball (tar.gz) file for *NIX
|
||||
* [Ubuntu 14.04](https://dotnetcli.blob.core.windows.net/dotnet/dev/Binaries/Latest/dotnet-linux-x64.latest.tar.gz)
|
||||
* [OS X 10.10](https://dotnetcli.blob.core.windows.net/dotnet/dev/Binaries/Latest/dotnet-osx-x64.latest.tar.gz)
|
||||
* [CentOS 7.1](https://dotnetcli.blob.core.windows.net/dotnet/dev/Binaries/Latest/dotnet-centos-x64.latest.tar.gz)
|
||||
|
||||
There will be two main ways to install things in a local fashion:
|
||||
|
||||
1. Manual way - download the archive of the tools over HTTP, install them in a wanted directory.
|
||||
2. Using the install.sh/install.ps1 scripts - this means that the user only acquires the script itself, which is then invoked with certain parameters and it does everything else.
|
||||
|
||||
>**Note:** as of this writing (12/21/2015) the scripts mentioned above still need some work to be usable in this regard. This document will be updated when we make those changes.
|
||||
|
||||
## Updating the bits
|
||||
|
||||
Once installed, how you update the bits depends on how you installed them.
|
||||
|
||||
### Windows MSI
|
||||
Uninstall your copy of CLI and then reinstall using the MSI.
|
||||
|
||||
### Ubuntu
|
||||
Use the following commands:
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install dotnet
|
||||
|
||||
This will refresh the apt-get feeds and install the latest version of the `dotnet` package.
|
||||
|
||||
### OS X PKG installer
|
||||
There is no real "update" PKG install. You can just re-run the latest PKG and it will rewrite the files in the destination and create new symlinks if there are any.
|
||||
|
||||
### OS X Homebrew formula
|
||||
Refer to [homebrew documentation](https://github.com/Homebrew/homebrew/tree/master/share/doc/homebrew#readme) for instructions, but usually it is the case of using `brew update $FORMULA` to update the specific formula to latest.
|
||||
|
||||
### Windows/*NIX local install
|
||||
Updating the bits is as easy as re-running the scripts with exactly the same parameters (i.e. the same target directory for the binaries) or redoing what you did for the manual install. Since there is no machine-wide location of the binaries that make up the CLI toolset, there is nothing more to be done.
|
||||
|
||||
## Removing the bits
|
||||
Removing the bits from the machine also depends on how you installed them.
|
||||
|
||||
### Windows MSI
|
||||
Uninstall the product using Control Panel.
|
||||
|
||||
### Ubuntu
|
||||
Use the following command:
|
||||
|
||||
sudo apt-get purge dotnet
|
||||
This will remove all traces of dotnet of your box.
|
||||
|
||||
### OS X PKG installer
|
||||
There is no "uninstall" of PKG installed software. There is a way, however, to see what files were installed and then manually remove them. [This SuperUser question](http://superuser.com/questions/36567/how-do-i-uninstall-any-apple-pkg-package-file) has all of the details on how would you do this.
|
||||
|
||||
### OS X Homebrew formula
|
||||
Refer to [homebrew documentation](https://github.com/Homebrew/homebrew/tree/master/share/doc/homebrew#readme) for instructions, but it is usually done with `brew uninstall $FORMULA`.
|
||||
|
||||
### Windows/*NIX local install
|
||||
Removing the local installs is as easy as removing the directories where you dropped the binaries.
|
||||
|
||||
72
Documentation/installation-scenarios.md
Normal file
72
Documentation/installation-scenarios.md
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
# General principles that apply to the installs
|
||||
- This doc is represnting ideal state and not the current state
|
||||
- Only HTTPS links are allowed in any online property
|
||||
- All installers are signed properly
|
||||
- All user facing materials point to the getting started page
|
||||
- The user needs extra effort to install the "bleeding edge" bits (nightly build)
|
||||
|
||||
# Landing Pages
|
||||
[Getting Started Page](https://aka.ms/dotnetcoregs) - for customers
|
||||
[Repo landing page](https://github.com/dotnet/cli/blob/rel/1.0.0/README.md) - for contributors
|
||||
|
||||
## Getting Started Page
|
||||
The page can be found on https://aka.ms/dotnetcoregs.
|
||||
|
||||
* Installation targets: native installers (bits) & "curl&run"
|
||||
* Source branch: rel/1.0.0
|
||||
* Debian feed: (now: Development; future: Production)
|
||||
* Installation script links: Latest from rel/1.0.0
|
||||
* Getting started page can never point to unstable builds
|
||||
* URLs point to: latest green build of rel/1.0.0;
|
||||
|
||||
This is the main curated first-run experience for the dotnet CLI. The intent of the page is to help users "kick the tires" quickly and become familiar with what the platform offers. This should be the most stable and curated experience we can offer.
|
||||
|
||||
## Repo Landing Page
|
||||
The repo landing page can be found on: https://github.com/dotnet/cli/readme.md
|
||||
* Source branch: rel/1.0.0
|
||||
* Links to builds: LKG ?? latest green build of rel/1.0.0 (build status)
|
||||
* The Repo Landing Page should be used primarily by contributors to the CLI
|
||||
* Only links to "how to install" but no instructions
|
||||
* First thing for "you want to get started" section should link to the getting started page on the marketing site
|
||||
* Separate page that has instructions on how to install both the latest stable as well as latest development with proper warnings around it. The separate page is to really avoid the situation from people accidentally installing unstable bits (since SEO can drop them in the repo first).
|
||||
|
||||
# Installation modes
|
||||
|
||||
## Interactive installation (native installers)
|
||||
These installation experiences are the primary way new users are getting the bits. They are aimed towards users kicking the tires. They are found using (not not limited to) the following means:
|
||||
|
||||
* Web searches
|
||||
* Marketing materials
|
||||
* Presentations
|
||||
* Documentation
|
||||
|
||||
The primary way to get information about this mode of installation is the marketing website.
|
||||
|
||||
The native installers are:
|
||||
|
||||
* Deb packages for Debian-based distros
|
||||
* RPM packages for RH-based distros
|
||||
* Bundles for Windows
|
||||
* PKG for OS X
|
||||
* Homebrew for OS X
|
||||
|
||||
## Curl & paste installation script
|
||||
### install.sh/install.ps1
|
||||
This approach will be used for the below scenarios:
|
||||
|
||||
* Local installation (consumed by build scripts)
|
||||
* Global installation (consumed by users who like command line)
|
||||
* Copy & paste script: downloads and executes installation script
|
||||
|
||||
**TODO:** add actual commands for both Unix and Windows.
|
||||
|
||||
## Docker
|
||||
* Link to docker hub page
|
||||
* Docker images are used either as a base or as small development envs for trying out the bits
|
||||
* Docker image should have stable bits
|
||||
* Should point to the "stable" tag
|
||||
|
||||
## Acquiring through other products (VS, VS Code)
|
||||
Visual Studio will chain the native installer. The version we give them is from the rel/1.0.0 branch.
|
||||
|
||||
VS Code extension will toast/point people to the installers (getting started page).
|
||||
Loading…
Reference in a new issue