An interoperable nominated Proof-of-Stake network for developing and running Substrate-based and EVM compatible blockchain applications.
Read more at selendra.org
Our mission is to bring blockchain benefits a step closer to the ordinary people who had been overlooked and underserved, and to accelerate the advancement and strengthening the industry as a whole.
Selendra project is inspired by the excellent work of many growing projects in the Polkadot ecosystem and many other blockchain developers around the world. Our progress in the past, the present and the future is only possible thanks to the open sources software community, framework, and tools. Thank you!
This is a work in progress, we will update more information as we progress further. Please refer to the token economy working paper for more details.
Brave Branch Strategy
prod => releases to production master || main => releases to staging dev => releases to development
Below is how we work with Branches.
gitGraph commit commit branch dev checkout dev commit branch members checkout members commit commit commit checkout dev merge members commit checkout main merge dev commit commit branch prod checkout prod commit commit id: "Release" tag: "v1.0.0"
production releases should only be made after have been able to test exactly what we're going to release on stage. So these should always be a PR from
"make production === stage". These are the only PRs that should go to
therefore a merge to
mastershould only happen when we think the feature is ready to release.
when starting a piece of work, create a branch off
masterand keep adding commits there until it's ready to release.
to test the code in a real environment, either:
- a. merge that branch to dev - but don't delete the feature branch. Repeatedly merge the feature that feature branch to dev as work progresses. Merges to dev do not require PRs. OR
- b. manually initiate the
"Deploy to Development"github action selecting that branch - this will deploy just those changes to development.
In-development QA of this feature should happen on the development environment.
when it's good to go merge the feature branch to
master- with a PR and security review if required.
Do not merge until all reviews are completed. then, after checking on the staging environment (including QA regression testing if needed) PR a production release as per step 1.
now and again we will reset dev to match
masterjust to keep the history tidy.