Decentralized collaboration in particular requires rules that are followed by everyone but also monitored by everyone. These rules must be adhered to by every collaborator, changes to these rules require a minimum number of reviews and there must be no objection (changes requested).
We have different branches in our repo, it is important to understand which branch is used for what, and which branch can be merged into which one until the release is finally published.
This branch reflects the currently published release. By default it is not possible for a single person to merge into this branch. It is subsequently also forbidden. Merges into this branch are exclusively done by a Github bot via a pull request, which must be reviewed through the collaborators before. A minimum number of reviews from the collaborators are necessary for a successful merge into the main branch.
This branch reflects the "dlt.green" installer.
Latest release from this branch can be found at:
https://github.com/dlt-green/node-installer-docker/releases/latest
This branch is intended as an intermediate step for testing further developments before it is released. Major changes may not be made directly in this branch. This is more intended to test the release beforehand. It must be possible at any time to release the dev branch promptly or immediately (e.g. for node updates or hotfixes). Small changes without objection from the collaborators can be pushed directly, which have no impact on functionality. If it is uncertain whether the necessary number of reviews will be achieved, or if there are changes to the functionality, open a feature branch for that (see next section).
This branch can be tested with the "dlt.green-dev" installer.
Latest release from this branch can be found at:
https://github.com/dlt-green/node-installer-docker/releases/tag/dev-latest
Feature branches are used for further development of the installer and should always be copied from the dev branch. Such a branch may only be opened with the consent of the collaborators or no objection from a collaborator. If you create a branch for a feature "xyz", then name it "feature/xyz" without exception. This branch will also be built immediately for testing, and the installer can also be started from this branch. You see the files under ”xyz-latest” as pre-release. If the feature is to be released soon, a pull request can be made into the dev branch. A pull request in the main branch will be deleted immediately without prior notice.
This branch can be tested with direct access to the pre-release.
Latest release from a specific feature branch can be found at:
https://github.com/dlt-green/node-installer-docker/releases/tag/xyz-latest
A pre-release for testing is automatically built for each branch. Since the installer and the files are monitored with hashes, these are automatically set by Github in the installer, no manual adjustment is necessary.
It is used for generating a pull request from dev branch into the main branch, after running the workflow a pull request is automatically generated to review from the collaborators, before it can be merged into the main branch. At the same time, a pre-release with the specified version was published, which becomes a release after review. In every pre-release version, the update flags (=the various VAR_[NETWORK]_[COMPONENT]_UPDATE=1
lines at the top of the installer script) are commented out in the installer
Since the image for the wasp cli on dockerhub is provided by dlt.green, this must be built and published for a new version. Here you just have to specify the corresponding wasp cli version for building.
- Fork the repository
- Make a squashed pull request into our dev-branch
- Give it a meaningful title and add a description
- If the collaborators agree (3 reviews/no changes requested), it will be merged or, if rejected, it will not be merged.
- Abide by the rules listed above
- Merging and preparing release may only be done through the dlt.green core team (dlt.green | 2g4y1 | Tito Bogenlos | Pascal Jeiziner)
- Titles of your commits must have the following structure: "part of the installer": "what is done" (e.g: "iota-wasp: update …", "wasp: fix …", "docker: …", "installer: add/rem/fix/update/upgrade/…"
- Titles of pull requests must be meaningful, and a description would be good to get faster reviews
- You need the approval (review) of at least 3 contributors and there must be no objection from any contributor (changes requested)
- It is advisable to find a consensus in our dlt.green x-team with the collabrators before acting in the repo, in order to subsequently receive the necessary reviews
- A new collaborator can be added with 75% approval via a vote with no objection from an active collaborator
- A collaborator can be deleted with 75% approval via a vote
- These rules must be reviewed by every collaborator
- Failure to comply with the rules will result in immediate exclusion without prior notice