mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.4.0 2022-05-27T14:18:52Z 2022-05-27T14:18:52Z Nick Mathewson nickm@torproject.org 2022-05-27T14:18:52Z urn:sha1:4326aa1de9875ea399c3a608c0320bbe4b214a42 This commit was made by reverting the previous commit, then re-running the script I used to generate it. In theory there should be no semantic changes: only changes due to improved formatting from cargo edit. 2022-05-27T13:01:20Z Nick Mathewson nickm@torproject.org 2022-05-27T13:01:20Z urn:sha1:b232365a75249d6f767127feb2a47286f9ece762 I followed the following procedure to make these changes: * I used maint/changed_crates to find out which crates had changed since 0.3.0. * I used grep and maint/list_crates to sort those crates in topological (dependency) order. * I looked through semver_status to find which crates were listed as having semver-relevant changes (new APIs and breaking changes). * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no changes. For those crates, I incremented their patch-level version _without_ changing the version that other crates depend on. * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no obvious breaking changes. * I treated all crates that depend on `arti` and/or `arti-client` as having breaking changes. * I identified crates that depend on crates that have changed, even if they have not changed themselves, and identified them as having a non-breaking change. * For all of the crates, I used `cargo set-version -p $CRATE --bump $STATUS` (where `STATUS` is `patch` or `minor`) to update the versions, and the depended-upon versions. 2022-05-23T20:02:50Z Nick Mathewson nickm@torproject.org 2022-05-23T20:02:50Z urn:sha1:c27b3cb70179eea0dc29d6029995d1d93b10987e 2022-05-09T19:59:38Z Nick Mathewson nickm@torproject.org 2022-03-10T21:38:23Z urn:sha1:3b0336e841f537196408f43a4928df20398c160d Relay nicknames are always between 1 and 19 characters long, and they're always ASCII: That means that storing them in a [u8;19] will always be possible, and always use less resources than storing them in a String. Fortunately, the tinystr crate already helps us with this kind of thing. 2022-05-06T14:03:15Z Nick Mathewson nickm@torproject.org 2022-05-06T14:03:15Z urn:sha1:7b93091f57f43ec8543a17052d60a2c8f7f2b0cc * Except for safelog and fs-mistrust, which are new. 2022-04-25T17:05:31Z Nick Mathewson nickm@torproject.org 2022-04-25T16:19:02Z urn:sha1:b60b0a266a145d36950df638c83f8c4d55b6ae0b This is an automated change made with a perl one-liner and verified with grep -L and grep -l. Some warnings are introduced with this change; they will be removed in subsequent commits. See arti#208 for older discussion on this issue. 2022-04-25T17:04:31Z Nick Mathewson nickm@torproject.org 2022-04-25T16:10:41Z urn:sha1:ca05b0904c2fbb0c866127a78728cab7be28d61f This change was made automatically with a perl one-liner, and confirmed with `grep -L`. The `rust-version` field itself was introduced in 1.56.0. 2022-04-25T17:04:31Z Nick Mathewson nickm@torproject.org 2022-04-25T16:03:41Z urn:sha1:0069fd2206b2cbc612474e7d70fda0af9cfcae2d There are no semantic changes here; only formatting. This is in preparation for other changes (wrt MSRV and edition) 2022-04-01T13:15:18Z Nick Mathewson nickm@torproject.org 2022-04-01T13:15:18Z urn:sha1:5b2fc118df0524144e6b2c34fdcce3d0fb692d24 Not all of these strictly need to be bumped to 0.2.0; many could go to 0.1.1 instead. But since everything at the tor-rtcompat and higher layers has had breaking API changes, it seems not so useful to distinguish. (It seems unlikely that anybody at this stage is depending on e.g. tor-protover but not arti-client.) 2022-03-31T14:34:11Z Ian Jackson iwj@torproject.org 2022-03-31T14:34:11Z urn:sha1:68b614ade1a92e10cc81a3bb7b7a19a15fd48dde