chore: replaces superficial references to Dfinity (dfinity#1818)

.github/CODEOWNERS

@@ -1,5 +1,5 @@
 # The whole SDK team owns the whole repo for now.
-* @dfinity-lab/sdk
+* @dfinity/dx
 
 # The infra team can still approve Nix PRs.
 **/*.nix @dfinity-lab/infra

.github/CONTRIBUTING.adoc

@@ -1,4 +1,4 @@
-= Contributing to the DFINITY SDK
+= Contributing to DFX
 
 == Developing `dfx`
 

.gitlab-ci.yml

@@ -11,12 +11,12 @@ before_script:
   - rm ~/.ssh/id_ed25519
   - mkdir -p $CI_JOB_STAGE/$CI_JOB_NAME
 
-# Run SDK tests against the upstream DFINITY repo.
+# Run SDK tests against the upstream repo.
 #
-# Typically this job is triggered from an upstream pipeline in the DFINITY
+# Typically this job is triggered from an upstream pipeline in the upstream
 # repo, but this job can still be run manually from within the GitLab pipeline UI.
 #
-# The following variables indicate which branch and commit in the DFINITY repo to run
+# The following variables indicate which branch and commit in the upstream repo to run
 # the SDK tests against.
 #
 #   SDK_TEST_BRANCH_NAME:

README.adoc

@@ -1,8 +1,8 @@
-= The DFINITY SDK
+= DFX
 
 == Getting Started
 
-`dfx` is the command-line interface for managing your DFINITY project and the best place to start.
+`dfx` is the command-line interface for managing your Internet Computer project and the best place to start.
 
 === Installing
 
@@ -17,7 +17,7 @@ This command will install a binary compatible with your operating system, and ad
 
 ==== via GitHub Releases
 
-Find a release for your architecture https://github.com/dfinity-lab/sdk/releases[here].
+Find a release for your architecture https://github.com/dfinity/dfx/releases[here].
 
 === Getting Help
 
@@ -32,7 +32,7 @@ See our contributing guidelines link:.github/CONTRIBUTING.adoc[here].
 
 == Release Process
 
-The SDK is released in two steps:
+DFX is released in two steps:
 
 1. Publishing a new DFX release.
 
@@ -41,7 +41,7 @@ The SDK is released in two steps:
 
 === Publising DFX
 
-1. The release manager makes sure the `sdk` `stable` branch points to the revision
+1. The release manager makes sure the `dfx` `stable` branch points to the revision
    that should be released and that the revision is tagged with a version (like
    `0.5.6`).
 

docs/process/release.adoc

@@ -1,12 +1,14 @@
 = Release process
 
-This document describes the release process for the DFINITY SDK, with step-by-step instructions, information about automation, and a checklist.
+This document describes the release process for `dfx`, with step-by-step instructions, information about automation, and a checklist.
 
 == Overview
 
 Before starting the release process, the team should conduct a brief Go/No-Go release review to evaluate the current state of fixes and features ready to be included in a release candidate.
 After reviewing the list of fixes and features, the team will decide whether to proceed with staging a build.
 
+For now, our release process is driven by the DFINITY foundation SDK team. Future work needs to be done to separate the build and release process to run fully on open systems.
+
 If the new release is given the Go green light, two people who are familiar with the process—a *driver* and a *validator*—use the steps in this document to stage or promote a release candidate.
 
 The *validator* should be the person most familiar with the process and be able to assist with debugging or resolving issues if the *driver* building the release runs into trouble.

docs/specification/version-management.adoc

@@ -13,9 +13,9 @@ This document details the design and decisions made to solve the problem of havi
 == User-facing Version
 The version of `dfx` is the only version the user should be aware of. Any upstream version will be hidden behind the `dfx` version.
 
-For example, assuming `v1.1.5` and `v1.2.3` of `dfx` are supported stable versions, with unstable being `v1.3.0-beta.1`, and assuming a version of the DFINITY client could be released with bug fixes that affect both the previous stable, current stable, and unstable releases, without changes to `dfx` itself we should release a `v1.1.6`, `v1.2.4` and `v1.3.0-beta.2` versions of `dfx` containing the DFINITY client with the fix included.
+For example, assuming `v1.1.5` and `v1.2.3` of `dfx` are supported stable versions, with unstable being `v1.3.0-beta.1`, and assuming a version of `dfx` could be released with bug fixes that affect both the previous stable, current stable, and unstable releases, without changes to `dfx` itself we should release a `v1.1.6`, `v1.2.4` and `v1.3.0-beta.2` versions of `dfx` containing `dfx` with the fix included.
 
-This means the user would never actually see the version of DFINITY client that they are running.
+This means the user would never actually see the version of `dfx` that they are running.
 
 == Installing `dfx`
 The user should initially download the SDK by using the following command:
@@ -34,7 +34,7 @@ This binary contains a number of things:
 The `dfx` global CLI then tries to find the version it should use (in order);
 
 . If a `DFX_VERSION` environment variable is set, use that version directly. If that version is not available in the cache, report the error and do not continue.
-. If there is a local DFINITY configuration file, it will use the version of the SDK specified in it (the `dfx_version` field). If that version is not available in the cache, it will try to download it from the Internet. If there is no connection, report the error and do not continue.
+. If there is a local `dfx` configuration file, it will use the version of the SDK specified in it (the `dfx_version` field). If that version is not available in the cache, it will try to download it from the Internet. If there is no connection, report the error and do not continue.
 . If there is an Internet connection, to a maximum of once a week, `dfx` will reach out to `sdk.dfinity.org` to find the latest version available.
 . If there is a user-level cache available, `dfx` will use the latest version already downloaded by the user that is not newer than the `dfx` global CLI version.
 . Finally, the global `dfx` comes versioned and will use that version number as a last resort. If that version is not part of the cache, it will use its internal tar file to bootstrap the user level cache.

public/default.nix

@@ -38,7 +38,7 @@ pkgs.lib.linuxOnly (
   pkgs.runCommandNoCC "install.sh" {
     # `revision` will be printed by `install.sh` as follows:
     #
-    #   log "Executing DFINITY SDK install script, commit: @revision@"
+    #   log "Executing DFX install script, commit: @revision@"
     revision = src.rev;
     preferLocalBuild = true;
     allowSubstitutes = false;

public/install/000_header.sh

@@ -4,7 +4,7 @@
 ## Borrowed from rustup (https://sh.rustup.rs)
 ##
 ## This is just a little script that can be downloaded from the internet to
-## install the DFINITY SDK. It just does platform detection, downloads the installer
+## install dfx. It just does platform detection, downloads the installer
 ## and runs it.
 ##
 ## You are NOT AUTHORIZED to remove any license agreements or prompts from the following script.

public/install/999_footer.sh

@@ -95,7 +95,7 @@ main() {
     # Read flags.
     read_flags "$@"
 
-    log "Executing DFINITY SDK install script, commit: $SCRIPT_COMMIT_DESC"
+    log "Executing dfx install script, commit: $SCRIPT_COMMIT_DESC"
 
     downloader --check
     need_cmd uname
@@ -133,7 +133,7 @@ main() {
 
     log "Creating uninstall script in ~/.cache/dfinity"
     mkdir -p "${HOME}/.cache/dfinity/"
-    # Ensure there is a way to uninstall dfinity sdk.
+    # Ensure there is a way to uninstall dfx
     install_uninstall_script
 
     log "Checking for latest release..."