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-23T16:55:37Z Nick Mathewson nickm@torproject.org 2022-05-23T16:32:31Z urn:sha1:546ae3000eb179aedc97de30b0ccdb1d45b93395 It's a little overzealous sometimes, but it's mostly to the good. 2022-05-12T17:50:26Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-12T17:15:39Z urn:sha1:be5bc04c02d5023c46a117a048bf0a659094f4eb This deletes many handcoded impls. It also generates lots of impls that we previously didn't have. 2022-05-12T15:57:56Z eta tor@eta.st 2022-05-12T15:57:56Z urn:sha1:2255778afa664ff059785d4d1f6790227a02d3b7 impl_standard_builder followup See merge request tpo/core/arti!505 2022-05-12T14:59:13Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-12T14:58:58Z urn:sha1:c1c6f2b376827c4ebb13bc08456f8355717d15e5 I have Plans for this macro. In particular: * I have a wip branch which tests that the Builder can be deserialised from an empty config (ie, that config reading of a config with a blank section for this item works). * I think we should autogenerate $Config::builder(), and promote that, rather than $ConfigBuilder::default(). This macro could do that. 2022-05-12T14:59:10Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-12T14:35:44Z urn:sha1:888d6e0511d01379d42ae154ac99ce2d9e84fd44 2022-05-12T14:42:51Z Nick Mathewson nickm@torproject.org 2022-05-12T14:42:51Z urn:sha1:2a5ee2c8c9ceb0141db842d944f619337e366bf1 Teach DirMgr to use slightly untimely directories Closes #467 and #412 See merge request tpo/core/arti!500 2022-05-12T10:34:53Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-12T09:09:46Z urn:sha1:04b8729d6baf411847ec89d29b97848781a96dbb Discovered by a test case in my local tree. The test case was macro-generated by an extension of impl_standard_builder (which macro istself currently awaiting review, arti!499) Have also sent an MR to update the upstream docs https://github.com/jean-airoldie/humantime-serde/pull/8 2022-05-11T16:42:38Z Nick Mathewson nickm@torproject.org 2022-05-11T16:42:38Z urn:sha1:dd20ac45abc2b231c85914fd115728f64233515c