libdrop is a library for sending/receiving files, primarily over meshnet, but WAN is also an option.
- The version must be set in
LIBDROP_RELEASE_NAMEenv variable before compiling the code. The value is embedded inside the binary as the release version. API callnorddrop_version()returns this string.
Branches used for development:
dev- development, faster moving branch. Moose tracker latest with context sharing.main- release branch, contains latest release. Moose tracker latest with context sharing.
Maintained release branches:
release/v5- Maintenance, for Linux, Apple.release/v6- Pre UniFFI. Android, Windows.release/v7- UniFFI. Android, Windows.
As of 6.4.0, 5.5.0, 7.0.0 versions libdrop needs to maintain two versions of Moose tracker. One with context sharing and the other with not. Both are not backwards compatible(in API and in between), thus Libdrop must maintain two release branches for a while.
Branches and releases must contain moose-no-context or moose-with-context in the name to
indicate which moose tracker is being used. This should be a temporary nuisance, a constant re-evaluation is needed.
- After the release the
mainbranch must be merged into thedevbranch. - After changes are introduced it might need an appsec review. This is especially true if the major semver component is increased.
-
Check the
changelog.mdfile and make appropriate missing changes if any. Enter new version in there at the top if not there. Preferrably there should be no version before the release happens because it's easy to assume it's an already released version. Prefer to have UNRELEASED as a placeholder. -
Tag the commit with changelog modifications.
-
Enjoy as Gitlab pipeline is triggered and produces builds for various platforms.
- if
changelog.mdwas forgotten to be updated before tagging - do not modify the existing tags or releases, just commit changes and go on. - If there are some problems with the release and there's a need to redo it:
- Delete the tag
- Re-create the release tag
- Manually delete artifacts in maven, swift bridge, libdrop-build as build artifacts will be already stored
- Proceed as usual
make -C testTestsuite takes a long time to complete so running specific tests might be preferential and much faster while developing. To run a specific testsuite:
SCENARIO=scenario_name make -C testBefore running the coverage you need to install the rustfilt demangler and grcov tool.
cargo install rustfilt grcovYou also need to include the llvm-tools-preview component
rustup component add llvm-tools-previewSCENARIO=scenario_name make -C test coveragemake -C test coverageudrop is an example client-server to test basic functionality of the library.
A container image can be built with the example binary ready for running:
run.py server runexport DROP_SERVER=172.17.0.2
cargo run --example udrop -- -l 0.0.0.0 transfer $DROP_SERVER <path><path> is whatever file or folder you want to transfer to the server.
You can verify the transfer by checking the file system in the server container under /root/<path>
echo -n "<absolute file path>" | sha256sum | cut -d " " -f1 | xxd -ps -r | basenc --base64url | tr -d '='Whenever IPv6 is used in a text form e.g. it is stored in the DB, included in the event, or passed as a callback argument we use the RFC 5952 for unique text representation.
This project is licensed under the terms of the GNU General Public License v3.0 only