Add release-it (#49)

* Add release-it

* Add release-it config and doc

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,77 @@
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and
+expression, level of experience, education, socio-economic status, nationality,
+personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the contacting the project lead or Sage Privacy Officer
+(privacyofficer@sagebase.org). The project team will review and investigate all
+complaints, and will respond in a way that it deems appropriate to the
+circumstances. The project team is obligated to maintain confidentiality with
+regard to the reporter of an incident. Further details of specific enforcement
+policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+<!-- Links -->
+
+[homepage]: https://www.contributor-covenant.org

.github/CONTRIBUTING.md

@@ -0,0 +1,147 @@
+# Contribution Guide
+
+A big welcome and thank you for considering contributing to this project.
+
+This project is a community effort and lives off your contributions, be it in
+the form of bug reports, feature requests, discussions, or fixes and other
+code changes.
+
+Reading and following these guidelines will help us make the contribution
+process easy and effective for everyone involved. It also communicates that you
+agree to respect the time of the developers managing and developing these open
+source projects. In return, we will reciprocate that respect by addressing your
+issue, assessing changes, and helping you finalize your pull requests.
+
+## Quicklinks
+
+- [Code of Conduct](#code-of-conduct)
+- [Getting Started](#getting-started)
+    - [Issues](#issues)
+    - [Pull Requests](#pull-requests)
+    - [Setup Development Environment](#setup-development-environment)
+    - [Testing](#testing)
+- [Release Procedure](#release-procedure)
+- [Getting Help](#getting-help)
+
+## Code of Conduct
+
+We take our open source community seriously and hold ourselves and other
+contributors to high standards of communication. By participating and
+contributing to this project, you agree to uphold our [Code of Conduct].
+
+## Getting Started
+
+Contributions are made to this repo via Issues and Pull Requests (PRs). A few
+general guidelines that cover both:
+
+- Search for existing Issues and PRs before creating your own.
+- We work hard to makes sure issues are handled in a timely manner but,
+  depending on the impact, it could take a while to investigate the root cause.
+  A friendly ping in the comment thread to the submitter or a contributor can
+  help draw attention if your issue is blocking.
+
+### Issues
+
+Issues should be used to report problems with this project, request a new
+feature, or to discuss potential changes before a PR is created. When you
+create a new Issue, a template will be loaded that will guide you through
+collecting and providing the information we need to investigate.
+
+If you find an Issue that addresses the problem you're having, please add your
+own reproduction information to the existing issue rather than creating a new
+one. Adding a [reaction] can also help be indicating to our maintainers that a
+particular problem is affecting more than just the reporter.
+
+### Pull Requests
+
+PRs to our repositories are always welcome and can be a quick way to get your
+fix or improvement slated for the next release. In general, PRs should:
+
+- Only fix/add the functionality in question **OR** address wide-spread
+  whitespace/style issues, not both.
+- Add unit or integration tests for fixed or changed functionality
+  (if a test suite already exists).
+- Address a single concern in the least number of changed lines as possible.
+- Include documentation in the repo or on our [docs site].
+- Be accompanied by a complete Pull Request template (loaded automatically
+  when a PR is created).
+
+For changes that address core functionality or would require breaking changes
+(e.g. a major release), it's best to open an Issue to discuss your proposal
+first. This is not required but can save time creating and reviewing changes.
+
+In general, we follow the [Forking Workflow]:
+
+1. Fork the repository to your own Github account
+2. Clone the project to your machine
+3. Create a branch locally with a succinct but descriptive name
+4. Commit changes to the branch
+5. Following any formatting and testing guidelines specific to this repo
+6. Push changes to your fork
+7. Open a PR in our repository and follow the PR template so that we can
+   efficiently review the changes.
+
+We recommend that you add this repository as an [upstream remote] to your local
+git repository so that you can fetch the latest updates.
+
+On your local machine make sure you have the latest version of the `main`
+branch from this upstream repository:
+
+    git checkout main
+    git pull upstream main
+
+### Setup Development Environment
+
+This project relies on Node tools and project-specific commands defined in
+[package.json] to streamline the development and testing. The command below will
+install the required development tools.
+
+    npm ci
+
+### Testing
+
+TBA
+
+## Release Procedure
+
+Maintainers are required to follow the procedure below when creating a new
+release. Releases are created with the npm package [release-it].
+
+1. [Identify whether the release is a major, minor or patch release.]
+2. Manually update the package version in these files
+   - [README.md]
+   - [projects/sage-angular/package.json]
+3. Obtain a [personal access token] (release-it only needs "repo" access; no
+   "admin" or other scopes).
+4. Make sure the token is [available as an environment variable].
+5. Preview the release information using one of the commands listed below. These
+   commands will not modify any local or remote files.
+    - `npm run release -- major --ci --dry-run`
+    - `npm run release -- minor --ci --dry-run`
+    - `npm run release -- patch --ci --dry-run`
+6. Create the release using one of the commands listed below.
+    - `npm run release -- major --ci`
+    - `npm run release -- minor --ci`
+    - `npm run release -- patch --ci`
+7. Check that the release has been successfully created on GitHub along with any
+   release artifacts that may have been created (GitHub Pages, Docker image
+   pushed to Docker registry, Python package published to PyPi, etc.).
+
+## Getting Help
+
+Join us on the XXX and post your question to the
+channel that best matches the topic of your request.
+
+<!-- Links -->
+
+[Code of Conduct]: CODE-OF-CONDUCT.md
+[upstream remote]: https://help.github.com/en/articles/configuring-a-remote-for-a-fork
+[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
+[Forking Workflow]: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
+[package.json]: ../package.json
+[release-it]: https://github.com/release-it/release-it
+[Identify whether the release is a major, minor or patch release.]: https://semver.org/#summary
+[personal access token]: https://github.com/settings/tokens/new?scopes=repo&description=release-it
+[available as an environment variable]: https://github.com/release-it/release-it/blob/master/docs/environment-variables.md
+[README.md]: ../README.md
+[projects/rocc-client/package.json]: ../projects/rocc-client/package.json

.release-it.json

@@ -0,0 +1,13 @@
+{
+  "git": {
+    "commitMessage": "Release ${version}",
+    "tagAnnotation": "${version}"
+  },
+  "npm": {
+    "publish": false
+  },
+  "github": {
+    "release": true,
+    "releaseName": "${version}"
+  }
+}