You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given a version number MAJOR.MINOR.BUILD, increment the:
61
+
62
+
1. MAJOR version when you make a significant update of the protocol (like Ethereum, Ethereum 2.0 is rather a new blockchain from Ethereum 1.0),
63
+
2. MINOR version when you introduce some breaking changes, and
64
+
3. BUILD version when you make non-breaking changes such as bug fixes, RPC modifications, code refactoring, test updates, etc.
62
65
63
-
We are very very welcome contributions from anyone, even if little change (eg. improving comment, formatter) can help us make Vite better!
66
+
## Branching
64
67
65
-
If you\`d like to contribute to vite, please fork, fix, commit and make a pull request. We\`ll review and handle the PR. Please
66
-
make sure your code follows our guidelines:
68
+
The `master` branch is the working branch for the next release.
69
+
- Breaking changes should not be merged into `master` unless as described below.
70
+
- Non-breaking changes should be merged into `master`.
71
+
72
+
1) A new branch should be checked out from `master` before releasing a new version.
73
+
- Say the latest version running on mainnet is 2.12.2, we can checkout a branch named `release_v2.12.3` from `master` for building, deploying on testnet, releasing the binary and deploying on mainnet.
74
+
75
+
2) A development branch for the next breaking changes, for example `v2.13`, will be checked out from `master`.
76
+
- Any commits from `master` are required to be merged into `v2.13` (or rebase `v2.13` onto `master`) as soon as possible.
77
+
- All unit tests and integration tests should pass before merging a pull request.
78
+
79
+
3) Merge `v2.13` into `master` and checkout `release_v2.13.0` from `master` before the mainnet upgrade.
80
+
- This means that v2.13.0 is the next release and there are no more releases of version 2.12.x.
81
+
- The branch `v2.13` reached end-of-life and a new branch `v2.14` for the next breaking changes should be checked out from `master`.
82
+
- From this point onwards, any new commits which are merged into `master` are based on version 2.13.
83
+
84
+
Any changes should be committed to your personal fork followed by opening a PR in the official repository.
85
+
86
+
## Contribution
67
87
68
-
- Code must be formatted&commented to the official Go [formatting](https://golang.org/doc/effective_go.html#formatting)&[comment](https://golang.org/doc/effective_go.html#commentary) guidelines
88
+
Thank you for considering to help out with the source code! We welcome any contributions no matter how small they are!
69
89
70
-
- Pull request is recommended to be base on `master` branch
90
+
If you'd like to contribute to go-vite, please fork, fix, commit and send a pull request for the maintainers to review and merge into the main code base.
71
91
92
+
Please make sure your contributions adhere to our coding guidelines:
72
93
94
+
- Code must adhere to the official Go [formatting](https://golang.org/doc/effective_go.html#formatting) guidelines.
95
+
- Code must be documented adhering to the official Go [commentary](https://golang.org/doc/effective_go.html#commentary) guidelines.
96
+
- Pull requests need to be based on and opened against the `master` branch.
73
97
74
98
## License
75
99
76
-
The go-vite source code is under [GPLv3](https://www.gnu.org/licenses/gpl-3.0.html), also announced in the `LICENSE` file
77
-
in our code repository.
100
+
The go-vite source code is licensed under [GPLv3](https://www.gnu.org/licenses/gpl-3.0.html), also included in the `LICENSE` file.
0 commit comments