Pull latest from savi-lang/base-standard-library

.github/workflows/library-check.yaml

@@ -34,7 +34,7 @@ jobs:
         shell: ${{ matrix.shell }}
     steps:
       - uses: actions/checkout@v2
-      - uses: savi-lang/action-install@v1.1.0
+      - uses: savi-lang/action-install@v1
       - run: savi deps update --for spec
       - run: savi run spec ${{ runner.os == 'Windows' && '--cross-compile=x86_64-unknown-windows-msvc' || '' }}
 
@@ -44,7 +44,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
-      - uses: savi-lang/action-install@v1.0.0
+      - uses: savi-lang/action-install@v1
       - run: savi format --check
 
   ##

.github/workflows/library-deps-update.yaml

@@ -21,7 +21,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: savi-lang/action-install@v1.0.0
+      - uses: savi-lang/action-install@v1
       - run: savi deps update --for spec
       - uses: peter-evans/create-pull-request@v4
         with:

.github/workflows/library-release.yaml

@@ -0,0 +1,61 @@
+# NOTE: This file comes from `savi-lang/base-standard-library`
+#
+# This workflow is responsible for automating the creation of a new release.
+# As an input, the workflow takes a version tag to apply to the latest commit.
+# The version tag name will also be the release's name in GitHub.
+# Release notes will auto-generated by GitHub based on Pull Requests history.
+#
+# With some minor modification (see comments in the job definition below),
+# this workflow can also build release binaries for all supported platforms,
+# and package them up as tarballs attached as assets to the release in GitHub.
+# This is not relevant for all libraries, because many libraries do not have
+# any executable binary that is relevant to build, so it is disabled by default,
+# but for those libraries that have one or more application binaries to build,
+# all you need to do is specify the binary manifest's name and enable that step.
+#
+# The workflow is triggered by workflow dispatch, which means to run it you
+# need to press the "Run Workflow" button on the Actions page for this workflow,
+# then enter the required inputs when prompted to do so.
+# It can also be triggered via the GitHub API if desired.
+
+name: library-release
+
+on:
+  workflow_dispatch:
+    inputs:
+      version-tag:
+        description: |
+          The name of the version to release (e.g. `v1.2.3` or `v0.20220131.0`).
+        required: true
+
+jobs:
+  all:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: savi-lang/action-install@v1
+
+      - uses: savi-lang/action-build-release@v1
+        # Remove the following `if: false` line and replace all occurrences of
+        # `my-app` placeholder with your application's bin manifest name
+        # to enable building release binaries for your application.
+        if: false
+        id: my-app
+        with:
+          manifest-name: my-app
+          tarball-name: my-app-${{ github.event.inputs.version-tag }}
+          all-platforms: true
+          macosx-accept-license: true
+          windows-accept-license: true
+
+      - uses: softprops/action-gh-release@v1
+        if: ${{ github.event.inputs.version-tag != '' }}
+        with:
+          tag_name: ${{ github.event.inputs.version-tag }}
+          generate_release_notes: true
+          token: ${{ secrets.BOT_GITHUB_TOKEN }} # (allows triggering workflows)
+
+          # Uncomment the following lines to upload release binaries.
+          # fail_on_unmatched_files: true
+          # files: |
+          #   ${{ steps.my-app.outputs.tarball-directory }}/*

CONTRIBUTING.md

@@ -0,0 +1,40 @@
+# Contributing
+
+Thanks for your interest in this project!
+
+Here's some helpful context and guidance for how to contribute.
+
+## Questions & Discussion
+
+If you want to talk about this project, please reach out to the maintainers in [the Zulip chat server for Savi](https://savi.zulipchat.com/).
+
+That's the best forum for any questions you might have or points you may want to raise for discussion. The people in our chat are open and friendly, and we welcome good faith, relevant discussions of all kinds.
+
+## Bug Reports & Feature Requests
+
+First, search [the issue tracker](../../issues) to check for any similar ticket relevant to your bug or feature idea that already exists. If it does, prefer adding a comment to that ticket. Otherwise, go ahead and [create a new ticket](../../issues/new/choose)!
+
+Please ensure that your bug report or idea is clear and actionable. It should be a ticket about improving the project, which can be closed after the improvement is made (or if we decide not to make that improvement).
+
+Issue tickets are not for general comments about the project, questions for personal learning, or open-ended discussions. Please use [the Zulip chat server for Savi](https://savi.zulipchat.com/) instead, where those kinds of discussions are welcome.
+
+## Code Improvements
+
+To make code improvements, please follow the standard [GitHub flow for pull requests](https://docs.github.com/en/get-started/quickstart/github-flow), using a short-lived feature branch.
+
+If you have commit access to the repository, it's okay to create feature branches on the main repository. Otherwise, everyone is able to create feature branches on their personal fork.
+
+We want to keep code changes easy to review, easy to understand in the commit history, and easy to revert if needed. In pursuit of this, please keep pull requests small and focused on one core idea. Use descriptive commit messages that will be easy for someone to understand when they're looking through the commit history years later. If your branch contains a lot of unfocused commits, please squash them into one or more meaningful commits before merging.
+
+Small investments of time on your part don't need any coordination ahead of time, but if you're going to invest a lot of time in making large changes, it's a good idea to confirm ahead of time that your changes will be desirable to the maintainers to merge. Try sharing your proposed approach in a relevant issue ticket or in [the Zulip chat server for Savi](https://savi.zulipchat.com/) to make sure you're using an approach that's going to be acceptable for the project.
+
+## Creating a Release
+
+If you're a regular contributor here, you may have commit access to this repository. If so, feel free to create a new release at any time one is desired, as long as the CI workflows are passing on the main branch.
+
+To create a release, go to [the `library-release` CI workflow in GitHub Actions](../../actions/workflows/library-release.yaml) and click the "Run Workflow" button there. When prompted, enter a version tag name for the release. Here's how to name the tag:
+
+- for stable projects (`v1.0.0` and higher) use [semantic versioning](https://semver.org/), including a `v` prefix before the number segments.
+- for pre-stable projects use a tag name like `v0.YYYYMMDD.N`, where `YYYYMMDD` is the current date in ISO-8601 format, and `N` is the lowest number released on that date, starting at zero and moving up with each subsequent release on the same day.
+
+If you don't have access to create a release yourself, reach out to one of the maintainers in [the Zulip chat server for Savi](https://savi.zulipchat.com/) or in an issue ticket or pull request that was recently closed that includes the change you want to release. One of us can help get it released soon.