mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.8 2024-09-30T13:04:32Z 2024-09-30T13:04:32Z Nick Mathewson nickm@torproject.org 2024-09-30T13:04:32Z urn:sha1:d6890da4b1f87fd5e834aeb0cc9a7cd4b1d99e88 Per our policy, every one of these gets a minor bump. Generated with: ``` for crate in $(./maint/list_crates | grep '^\(tor\|arti\)-' ); do cargo set-version --bump minor -p $crate; done ``` (Note the use of `-` at the end end of the grep pattern to prevent matching the `arti` crate.) 2024-09-30T12:56:28Z Nick Mathewson nickm@torproject.org 2024-09-30T12:56:28Z urn:sha1:b29dd6d7f90cf077e8809a1ab317e23535e165c8 These crates are not in the tor/arti namespace, but we have given them MSRV bumps: ``` oneshot-fused-workaround slotmap-careful fslock-guard hashx equix caret fs-mistrust safelog test-temp-dir retry-error ``` We are counting this as a breaking change. Since all of these crates are at 0.x.x, we have indicated the breaking change with a minor version bump. This commit was generated with the following script: ``` BUMPS=" oneshot-fused-workaround slotmap-careful fslock-guard hashx equix caret fs-mistrust safelog test-temp-dir retry-error " for crate in $BUMPS; do cargo set-version --bump minor -p $crate; done ``` 2024-09-26T14:24:02Z David Goulet dgoulet@torproject.org 2024-09-26T14:24:02Z urn:sha1:2ad24dd46615d908cefa68f5a9752d4863b89b6c Upgrade MSRV to 1.77 , and rusqlite to 0.32.1 See merge request tpo/core/arti!2451 2024-09-26T01:54:22Z Nick Mathewson nickm@torproject.org 2024-09-25T14:46:08Z urn:sha1:ff9e93a2a10ef02f436c6f7d7a05739a818b094a This will allow us to upgrade to the latest version of rusqlite. 2024-09-25T14:37:18Z Nick Mathewson nickm@torproject.org 2024-09-25T14:37:18Z urn:sha1:6a12c2ba8515226a772d5f4a81930bf42d67535a The `derive_more` crate broke backward compatibility with this version, so this change involved quite a few manual fixups. With luck, they'll keep compatibility for some while in the future. 2024-09-16T21:18:31Z Wesley Aptekar-Cassels me@wesleyac.com 2024-09-16T21:18:31Z urn:sha1:4d1ec233ceadfd1326d0643bd215051e71f95b84 2024-09-12T11:48:39Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-11T15:52:29Z urn:sha1:8c2c1170daa9b1fc4a13177edd3881e934b99899 2024-09-12T11:48:38Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-11T15:51:40Z urn:sha1:5314741adecad01014a069c4f0ed5018e0f6c207 No semver implications since this wasn't in the last release. 2024-09-11T13:19:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-11T12:04:46Z urn:sha1:98e563764b428e4f1aa87dc34e5fa6b5cf296938 We could call from_possibly_incomplete_slice in these, but that's confusing and distracting. Here we add this constructor, and document it (in terms of the constructor to come), and change the call sites. No functional change. Doing this now will prevent unwanted changes to test behaviours when we change the behaviour of Readers made by Reader::from_slice. 2024-09-11T12:22:39Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T14:34:52Z urn:sha1:040db873ed95f9d24ed9d0162d75b9c8a11e457f The codebase uses `r` sometimes and `b` at other times. Making this consistent makes widespread changes easier, and is clearer for humans. I think `b` is better than `r` because `r` might be "return". It is indeed used that way in a couple of places in reader.rs, even. I haven't changed *everywhere*, just Readable impls (where `r` is particularly likely to be "return value") and occurrences in tor-bytes. No functional change.