Skip to content

vitelabs/go-vite

Folders and files

NameName
Last commit message
Last commit date

Latest commit

LeonardoBillLeonardoBill
LeonardoBill
and
LeonardoBill
Dec 1, 2022
25b479e · Dec 1, 2022
Sep 11, 2022
Sep 7, 2021
May 24, 2022
Jun 6, 2022
Aug 11, 2022
May 30, 2022
May 24, 2022
Dec 18, 2021
May 19, 2022
Jul 19, 2022
Jul 20, 2022
Apr 2, 2019
Feb 22, 2022
May 5, 2022
Dec 1, 2022
Dec 18, 2021
Jul 20, 2022
Nov 30, 2022
Dec 1, 2022
May 9, 2021
Dec 18, 2021
Dec 1, 2022
Dec 1, 2022
Dec 18, 2021
Nov 26, 2022
Dec 27, 2021
Mar 20, 2022
Dec 25, 2018
May 14, 2018
Jul 18, 2022
May 6, 2022
Dec 18, 2021
Dec 18, 2021
Jul 23, 2020
Jun 6, 2022
Apr 1, 2022

Repository files navigation

Logo

Vite is a next-generation Reactive Blockchain that adopts a message-driven, asynchronous architecture and a DAG-based ledger. The goal for Vite’s design is to provide a reliable public platform for industrial dApps, with features of ultra-high throughput and scalability.

Go Vite

Official golang implementation of Vite Protocol

GitHub release Go Report Card GitHub closed pull requests Downloads

The go-vite binary files can be download from releases.

Guides & Documentation

Product

Links & Resources

Installation

You can choose one of the following installation options:

Faster ledger sync

download gvite ledger file manually.

Versioning

Given a version number MAJOR.MINOR.BUILD, increment the:

  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),
  2. MINOR version when you introduce some breaking changes, and
  3. BUILD version when you make non-breaking changes such as bug fixes, RPC modifications, code refactoring, test updates, etc.

Branching

The master branch is the working branch for the next release.

  • Breaking changes should not be merged into master unless as described below.
  • Non-breaking changes should be merged into master.
  1. A new branch should be checked out from master before releasing a new version.

    • 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.
  2. A development branch for the next breaking changes, for example v2.13, will be checked out from master.

    • Any commits from master are required to be merged into v2.13 (or rebase v2.13 onto master) as soon as possible.
    • All unit tests and integration tests should pass before merging a pull request.
  3. Merge v2.13 into master and checkout release_v2.13.0 from master before the mainnet upgrade.

    • This means that v2.13.0 is the next release and there are no more releases of version 2.12.x.
    • 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.
    • From this point onwards, any new commits which are merged into master are based on version 2.13.

Any changes should be committed to your personal fork followed by opening a PR in the official repository.

Contribution

Thank you for considering to help out with the source code! We welcome any contributions no matter how small they are!

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.

Please make sure your contributions adhere to our coding guidelines:

  • Code must adhere to the official Go formatting guidelines.
  • Code must be documented adhering to the official Go commentary guidelines.
  • Pull requests need to be based on and opened against the master branch.
  • Open an issue before submitting a PR for non-breaking changes.
  • Publish a VEP proposal before submitting a PR for breaking changes.

License

The go-vite source code is licensed under GPLv3, also included in the LICENSE file.