Skip to content

Commit

Permalink
doc: add CHANGELOG.md and update CONTRIBUTING.md (near#4580)
Browse files Browse the repository at this point in the history
Added `CHANGELOG.md` to document the protocol changes in each release going forward. Also updated `CONTRIBUTING.md`  to add how to update change log and remove some outdated information.
  • Loading branch information
bowenwang1996 authored Jul 28, 2021
1 parent 28d9b7d commit c0d382b
Show file tree
Hide file tree
Showing 2 changed files with 28 additions and 5 deletions.
21 changes: 21 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Changelog

## [unreleased]

## `1.20.0` [07-26-2021]

### Protocol Changes

* Introduce new host functions `ecrecover` and `ripemd160`. [#4380](https://github.com/near/nearcore/pull/4380)
* Make `Account` a versioned struct. [#4089](https://github.com/near/nearcore/pull/4089)
* Limit the size of transactions to 4MB. [#4107](https://github.com/near/nearcore/pull/4107)
* Cap maximum gas price to 20x of minimum gas price. [#4308](https://github.com/near/nearcore/pull/4308), [#4382](https://github.com/near/nearcore/pull/4382)
* Fix `storageUsage` for accounts that were affected by [#3824](https://github.com/near/nearcore/issues/3824). [#4272](https://github.com/near/nearcore/pull/4274)
* Fix a bug in computation of gas for refunds. [#4405](https://github.com/near/nearcore/pull/4405)

### Non-protocol changes

* Compile contracts after state sync. [#4344](https://github.com/near/nearcore/pull/4344)
* Introduce `max_gas_burnt_view` config for rpc. [#4381](https://github.com/near/nearcore/pull/4381)
* Fix wasmer 0.17 memory leak [#4411](https://github.com/near/nearcore/pull/4411)

12 changes: 7 additions & 5 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,8 +49,11 @@ The `test plan` should describe in detail what tests are presented, and what cas
### After the PR is submitted

1. We have a CI process configured to run all the sanity tests on each PR. If the CI fails on your PR, you need to fix it before it will be reviewed.
2. Once the CI passes, you should expect the first feedback to appear within 48 hours. The reviewers will first review your tests, and make sure that they can convince themselves the test coverage is adequate before they even look into the change, so make sure you tested all the corner cases.
2. Once the CI passes, you should expect the first feedback to appear within 48 hours.
The reviewers will first review your tests, and make sure that they can convince themselves the test coverage is adequate before they even look into the change, so make sure you tested all the corner cases.
If you would like to request review from a specific review, feel free to do so [through the github UI](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review).
3. Once you address all the comments, and your PR is accepted, we will take care of merging it.
4. If your PR introduces a new protocol feature, please document it in [CHANGELOG.md](CHANGELOG.md) under `unreleased`.

## Proposing new ideas and features

Expand Down Expand Up @@ -85,10 +88,9 @@ This is required by [cargo-workspaces](https://github.com/pksunkara/cargo-worksp

Once your change ends up in master, it will be released with the rest of the changes by other contributors on the regular release schedules.

You should expect the changes from `master` to get merged into `beta` branch the next time `nightly` test run completes, assuming it passes.
Releases to the `stable` branch are manual, but generally contain a contiguous prefix of commits from `beta` branch.
Note, that the goal is to maintain `beta` as stable as possible and `stable` completely stable. Hence if your change is breaking something that gets detected down the line - it will rolled back and requested to address the issue with additional test coverage.

On [betanet](https://docs.near.org/docs/concepts/networks#betanet) we run nightly build from master with all the nightly protocol feature enabled.
Every six weeks, we stabilize some protocol features and make a release candidate for testnet.
After the release candidate has been running on testnet for 2 weeks and no issue is observed, we stabilize and publish the release for mainnet.

## Issue Labels

Expand Down

0 comments on commit c0d382b

Please sign in to comment.