|
|
|
|
@@ -8,32 +8,32 @@ It is best to keep doc/relnotes/README.md up to date as changes and bug fixes ar
|
|
|
|
|
|
|
|
|
|
## Branch model
|
|
|
|
|
|
|
|
|
|
Development happens on the `dev` branch. Releases are cut on the default branch, `dragonx`. There is no `master` branch. Code changes should land on `dev` first and undergo testing before being merged into `dragonx`.
|
|
|
|
|
Development happens on the `dev` branch. Releases are cut on the default branch, `master`. Code changes should land on `dev` first and undergo testing before being merged into `master`.
|
|
|
|
|
|
|
|
|
|
## Check for changes on dragonx that should be on dev
|
|
|
|
|
## Check for changes on master that should be on dev
|
|
|
|
|
|
|
|
|
|
Occasionally trivial changes are made directly on the `dragonx` branch, such as documentation changes. In theory, no code changes should happen on `dragonx` without being on `dev` first, but it's better to be safe than sorry. We want the `dev` branch which undergoes testing to be as close as possible to what the `dragonx` branch will become, so we don't want to merge `dev` into `dragonx` and just assume everything works. So it's best to merge the `dragonx` branch into `dev` just before merging the `dev` branch into `dragonx`.
|
|
|
|
|
Occasionally trivial changes are made directly on the `master` branch, such as documentation changes. In theory, no code changes should happen on `master` without being on `dev` first, but it's better to be safe than sorry. We want the `dev` branch which undergoes testing to be as close as possible to what the `master` branch will become, so we don't want to merge `dev` into `master` and just assume everything works. So it's best to merge the `master` branch into `dev` just before merging the `dev` branch into `master`.
|
|
|
|
|
|
|
|
|
|
To check if the `dragonx` branch has any changes that the `dev` branch does not:
|
|
|
|
|
To check if the `master` branch has any changes that the `dev` branch does not:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
# this assumes you are working with https://git.dragonx.is/DragonX/dragonx as your remote
|
|
|
|
|
git checkout dev
|
|
|
|
|
git pull # make sure dev is up to date
|
|
|
|
|
git checkout dragonx
|
|
|
|
|
git pull # make sure dragonx is up to date
|
|
|
|
|
git diff dev...dragonx # look at the set of changes which exist in dragonx but not dev
|
|
|
|
|
git checkout master
|
|
|
|
|
git pull # make sure master is up to date
|
|
|
|
|
git diff dev...master # look at the set of changes which exist in master but not dev
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
If the last command has no output, congrats, there is nothing to do. If the last command has output, then you should merge `dragonx` into `dev`:
|
|
|
|
|
If the last command has no output, congrats, there is nothing to do. If the last command has output, then you should merge `master` into `dev`:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
git checkout dev
|
|
|
|
|
git merge dragonx
|
|
|
|
|
git merge master
|
|
|
|
|
git push origin dev
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Use the `--no-ff` flag when merging `dev` into `dragonx` for a release (see below). The `--no-ff` flag makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
|
|
|
|
|
Use the `--no-ff` flag when merging `dev` into `master` for a release (see below). The `--no-ff` flag makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Git Issues
|
|
|
|
|
@@ -66,6 +66,7 @@ Install deps on Linux:
|
|
|
|
|
- Run "make seeds"
|
|
|
|
|
- Commit the result
|
|
|
|
|
- Update version in configure.ac and src/clientversion.h to update the dragonxd version
|
|
|
|
|
- **The new version MUST be higher than every version already tagged**, including tags that were never built or published. Check with `git tag -l --sort=-v:refname | head`. Two trees stamped with the same `CLIENT_VERSION` are indistinguishable on the wire, in `getnetworkinfo`, and to the wallet's in-app updater — and a published archive that does not match its tag destroys the only provenance check users have.
|
|
|
|
|
- In src/clientversion.h you update `CLIENT_VERSION_*` variables. Usually you will just update `CLIENT_VERSION_REVISION`
|
|
|
|
|
- If there is a consensus change, it may be a good idea to update `CLIENT_VERSION_MINOR` or `CLIENT_VERSION_MAJOR`
|
|
|
|
|
- To make a pre-release "beta" you can modify `CLIENT_VERSION_BUILD` but that is rarely done.
|
|
|
|
|
@@ -97,17 +98,27 @@ Install deps on Linux:
|
|
|
|
|
- Try to generate checkpoints as close to the release as possible, so you can have a recent block height be protected.
|
|
|
|
|
- For instance, don't update checkpoints and then do a release a month later. You can always update checkpoint data again or multiple times
|
|
|
|
|
- Update doc/relnotes/README.md
|
|
|
|
|
- To get the stats of file changes: `git diff --stat dragonx...dev`
|
|
|
|
|
- To get the stats of file changes: `git diff --stat master...dev`
|
|
|
|
|
- Do a fresh clone and fresh sync with new checkpoints
|
|
|
|
|
- Stop node, wait 20 minutes, and then do a partial sync with new checkpoints
|
|
|
|
|
- Merge dev into dragonx: `git checkout dev && git pull && git checkout dragonx && git pull && git merge --no-ff dev && git push`
|
|
|
|
|
- Merge dev into master: `git checkout dev && git pull && git checkout master && git pull && git merge --no-ff dev && git push`
|
|
|
|
|
- The above command makes sure that your local dev branch is up to date before doing anything
|
|
|
|
|
- The above command will not merge if "git pull" creates a merge conflict
|
|
|
|
|
- The above command will not push if there is a problem with merging dev
|
|
|
|
|
- Make Gitea release with git tag from the dragonx branch (make sure to merge dev in first)
|
|
|
|
|
- Make Gitea release with git tag from the master branch (make sure to merge dev in first)
|
|
|
|
|
- Make sure git tag starts with a `v` such as `v1.0.3`
|
|
|
|
|
- Use util/gen-linux-binary-release.sh to make a Linux release binary
|
|
|
|
|
- Upload Linux binary to Gitea release and add SHA256 sum
|
|
|
|
|
- **The tag MUST be annotated** (`git tag -a v1.3.0 -m 'DragonX v1.3.0'`), not lightweight. `util/genbuild.sh` calls `git describe` *without* `--tags`, which only ever sees annotated tags — a lightweight tag makes the build stamp itself `v<older-tag>-<sha>` instead of the release version. v1.0.0 through v1.0.3 are lightweight, which is why their builds are labelled that way.
|
|
|
|
|
- Verify before building: `git describe` must print exactly the tag, with no `-<n>-g<sha>` suffix.
|
|
|
|
|
- Use `./build.sh` (container-based, see doc/build-containers.md) or util/gen-linux-binary-release.sh to make a Linux release binary
|
|
|
|
|
- **Sign every archive and publish the signatures.** This step is mandatory and was missing from this document until v1.3.0 — its absence is why v1.1.0 and v1.2.0 were tagged but never became installable releases.
|
|
|
|
|
- The wallet's in-app daemon updater pins an ed25519 public key in `ObsidianDragon/src/util/daemon_updater.h` and sets `kDaemonRequireSignature = true`. **An update is refused outright unless a valid `<archive>.sig` is published beside the archive.** No signature means every existing user silently stays on their old daemon.
|
|
|
|
|
- Sign with `ObsidianDragon/scripts/sign-daemon-release.sh`:
|
|
|
|
|
- `scripts/sign-daemon-release.sh sign <secret.key> <archive>...` produces `<archive>.sig` (base64 of a detached 64-byte ed25519 signature over the exact archive bytes)
|
|
|
|
|
- or `scripts/sign-daemon-release.sh release <secret.key> <version>` to zip, sign, and print the checksum table in one step
|
|
|
|
|
- Keep the secret key offline, mode 600. The matching base64 public key must already be pinned in `kDaemonSignaturePublicKeyBase64`.
|
|
|
|
|
- Upload each Linux binary archive **and its `.sig`** to the Gitea release
|
|
|
|
|
- **Paste the SHA-256 checksum table into the release body** as markdown rows of the form `| <archive>.zip | `<sha256hex>` |`. The updater parses this table and will not install an archive that is absent from it.
|
|
|
|
|
- Confirm the release is actually consumable before announcing it: the updater looks for an asset whose name contains `"-" + platformToken + ".zip"` (`linux-amd64`, `macos`, `win64`). An archive named for a distro variant instead of the platform token is invisible to it.
|
|
|
|
|
- Create an x86 Debian package for the release:
|
|
|
|
|
- Edit contrib/debian/changelog to add information about the new release
|
|
|
|
|
- Use `util/build-debian-package.sh` to make an x86 Debian package for the release
|
|
|
|
|
@@ -115,7 +126,7 @@ Install deps on Linux:
|
|
|
|
|
- `lintian` is an optional dependency, it's not needed to build the .deb
|
|
|
|
|
- Upload .deb to Gitea release
|
|
|
|
|
- Add SHA256 checksum of .deb to release
|
|
|
|
|
- Use util/build-debian-package-ARM.sh (does this still work?) to make an ARM Debian package for the release
|
|
|
|
|
- ARM Debian package: `util/build-debian-package-ARM.sh` is referenced here historically but **is not present in the tree**. Skip, or restore the script first.
|
|
|
|
|
- Upload the debian packages to the Gitea release page, with SHA256 sums
|
|
|
|
|
|
|
|
|
|
## Platform-specific notes
|
|
|
|
|
|
