Download releases from the main repo (#1387)

RELEASES.md

@@ -0,0 +1,72 @@
+# Enso 0.2.0 (2021-01-05)
+
+## Language
+
+The initial version of the Enso language, with most language features
+functioning.
+
+- Flexible and concise syntax for the construction of functional programs,
+  including pattern matching and lambdas.
+- Support for currying, named and defaulted arguments, and operator sections.
+- Support for user-defined data-types with fields and dynamically-dispatched
+  methods on them.
+- Importing and working with Java code in a seamless fashion using polyglot
+  imports.
+- Functional monadic state and error handling, through the use of data errors
+  and panics.
+- Opt-in tail-call optimisation.
+
+## Interpreter/Runtime
+
+- The initial version of the interpreter and runtime.
+
+## Type System
+
+- Nothing.
+
+## Tooling
+
+- The initial version of the Enso Launcher and Project Manager, supporting:
+  - Installation and management of Enso releases, and the GraalVM runtimes on
+    which they depend.
+  - Aggregation of logs from the various Enso service components.
+  - Basic project management functionality.
+  - Initialisation and set-up of a language server for a specific project.
+- The initial version of the Enso Language Server, supporting:
+  - Dynamic introspection and modification of the running Enso program.
+  - Caching of intermediate values in computations, ensuring that only necessary
+    parts of the program are recomputed on a change.
+  - Intelligent suggestions based on semantic analysis of the code.
+  - Attaching visualisation code to values in the running Enso program.
+
+## Libraries
+
+- The initial version of `Base`, the core library, supporting:
+  - Functionality for working with core types like `Integer`, `Decimal`, and
+    `Text`.
+  - Common data structures such as `List`, `Vector`, and `Map`.
+  - Support for working with `JSON` data.
+  - Support for working with `HTTP` endpoints.
+  - Support for interacting with files and processes on the local machine.
+  - Support for working with polyglot entities.
+  - Support for metaprogramming the Enso language.
+- The initial version of the Enso `Table` library for working with tabular data.
+- The initial version of the Enso `Test` library, containing testing and
+  benchmarking utilities.
+
+## Stabilised Features
+
+- A list of stabilised APIs and/or features.
+
+## Misc
+
+- Nothing.
+
+## Known Issues
+
+- This is a beta release, so please see the issue tracker for issues opened
+  before the release date.
+
+## Internal Only
+
+- Nothing

build.sbt

@@ -15,13 +15,13 @@ val scalacVersion = "2.13.3"
 val rustVersion   = "1.40.0-nightly (b520af6fd 2019-11-03)"
 val graalVersion  = "20.2.0"
 val javaVersion   = "11"
-val ensoVersion   = "0.1.0-SNAPSHOT" // Note [Engine And Launcher Version]
+val ensoVersion   = "0.2.0-SNAPSHOT" // Note [Engine And Launcher Version]
 
 /* Note [Engine And Launcher Version]
  * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  * Currently both Engine and Launcher versions are tied to each other - each new
  * releases contains the Engine and the Launcher and thus the version number is
- * shared. If the version numbers ever diverge, make sure tu update the build
+ * shared. If the version numbers ever diverge, make sure to update the build
  * scripts at .github/workflows accordingly.
  */
 

docs/distribution/packaging.md

@@ -102,7 +102,7 @@ The following is an example of this manifest file.
 license: MIT
 name: My_Package
 version: 1.0.1
-enso-version: 0.1.0
+enso-version: 0.2.0
 authors:
   - name: John Doe
     email: john.doe@example.com

docs/distribution/release-policy.md

@@ -67,7 +67,7 @@ Release branches obey the following rules:
 - A release branch must contain _tags_ corresponding to released versions of
   Enso. Once a release has been made, no further changes may be made to that
   release.
-- A tagged release must contain a `CHANGELOG` file that describes the changes
+- A tagged release must contain a `RELEASES.md` file that describes the changes
   contained in that release.
 
 It should be noted that general development still takes place on the `main`
@@ -79,9 +79,10 @@ Cutting a release for Enso proceeds as follows:
 
 1.  If no release branch exists for the current major version, one should be
     created.
-2.  Release notes should be made up to date.
-3.  A commit representing the release should be tagged, and the tag pushed to
-    GitHub.
+2.  Release notes should be made up to date in `RELEASES.md` and committed to
+    the release branch.
+3.  A commit representing the release should be tagged on the release branch,
+    and the tag pushed to GitHub.
 4.  CI will create a draft release for this tag, as well as build and upload the
     appropriate artefacts.
 5.  The release notes for the version being released should be copied into the
@@ -90,6 +91,8 @@ Cutting a release for Enso proceeds as follows:
     team.
 7.  Once approval has been gained from these members, the release may be made
     official.
+8.  Push a commit to `main` bumping the version number and ensuring that it
+    remains a `SNAPSHOT` version.
 
 ### Tag Naming
 
@@ -99,6 +102,9 @@ released.
 
 ### Manifest Files
 
+Manifest files are used to describe metadata about various releases for use by
+the Enso tooling.
+
 #### Engine Manifest
 
 Each GitHub release contains an asset named `manifest.yaml` which is a YAML file
@@ -260,7 +266,8 @@ that will persist the broken mark to S3 is not triggered for release drafts.
 ### Release Notes
 
 Release notes should contain a summary of the changes made between the last
-release and the current release. They should follow the template given below:
+release and the current release. They should follow the template given below,
+and are contained in the `RELEASES.md` file in the repository root.
 
 ```md
 # Enso x.y.z (YYYY-MM-DD)
@@ -269,17 +276,13 @@ release and the current release. They should follow the template given below:
 
 - A list of language-level changes.
 
-## Type System
-
-- A list of type-system changes.
-
-## Interpreter
+## Interpreter/Runtime
 
 - A list of changes to the Enso interpreter.
 
-## Runtime
+## Type System
 
-- A list of changes to the Enso runtime.
+- A list of type-system changes.
 
 ## Tooling
 
@@ -306,7 +309,7 @@ release and the current release. They should follow the template given below:
 If there are no changes for a section, the section should contain a bullet point
 that reads "Nothing".
 
-The changelog file is an ongoing record of changes, and may diverge between
+The releases file is an ongoing record of changes, and may diverge between
 `main` and the various release branches.
 
 ## Version Support

docs/getting-enso.md

@@ -13,7 +13,7 @@ Enso packages can currently be obtained from the per-commit CI builds. See
 which should show a list of recent CI builds. The workflow of interest is
 `Engine CI`. You can navigate to the most recent build, which will display a
 list of attached artifacts. The artifact of interest is `enso-engine-<version>`
-(currently `enso-engine-0.1.0`).
+(currently `enso-engine-0.2.0-SNAPSHOT`).
 
 <!-- MarkdownTOC levels="2,3" autolink="true" -->
 

lib/scala/runtime-version-manager/src/main/scala/org/enso/runtimeversionmanager/releases/engine/EngineRepository.scala

@@ -8,12 +8,7 @@ import org.enso.runtimeversionmanager.releases.local.LocalReleaseProvider
 
 /** Represents the default Enso repository providing releases of the engine. */
 object EngineRepository {
-  // TODO [RW] The release provider will be moved from staging to the main
-  //  repository, when the first official Enso release is released.
-  val githubRepository = new GithubReleaseProvider(
-    "enso-org",
-    "enso-staging"
-  )
+  val githubRepository = new GithubReleaseProvider("enso-org", "enso")
 
   /** Default provider of engine releases. */
   def defaultEngineReleaseProvider: ReleaseProvider[EngineRelease] =