alex/anymap
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
anymap/Cargo.toml

21 lines
816 B
TOML
Raw Normal View History

Enabled Cargo and moved Makefile to use target.
2014-06-25 14:44:35 +10:00
[package]
name = "anymap"
0.12.1
2017-01-20 23:43:13 +11:00
version = "0.12.1"
Refresh Cargo.toml, README.md Remove superfluous things, update useful things.
2022-01-25 12:56:30 +11:00
authors = ["Chris Morgan <rust@chrismorgan.info>"]
Switch from 2015 edition to 2018 1.34 is safe for that.
2022-01-25 19:41:10 +11:00
edition = "2018"
no_std support I’m quite pleased with how this has turned out. Given the stability-despite-instability of hashbrown (that the API surface we’re depending on hasn’t changed since 0.1.1), and the deliberate altered SemVer guarantees for it, it was very tempting to leave the hashbrown range open, `version = ">=0.1.1"` or at least `version = ">=0.1.1, <1"`, but for some reason or other I ended up deciding not to. I’m still of two minds about it, really.
2022-01-25 21:24:48 +11:00
rust-version = "1.36"
Update metadata, 0.9.2.
2014-11-28 17:18:16 +11:00
description = "A safe and convenient store for one value of each type"
repository = "https://github.com/chris-morgan/anymap"
Refresh Cargo.toml, README.md Remove superfluous things, update useful things.
2022-01-25 12:56:30 +11:00
keywords = ["container", "any", "map"]
no_std support I’m quite pleased with how this has turned out. Given the stability-despite-instability of hashbrown (that the API surface we’re depending on hasn’t changed since 0.1.1), and the deliberate altered SemVer guarantees for it, it was very tempting to leave the hashbrown range open, `version = ">=0.1.1"` or at least `version = ">=0.1.1, <1"`, but for some reason or other I ended up deciding not to. I’m still of two minds about it, really.
2022-01-25 21:24:48 +11:00
categories = ["rust-patterns", "data-structures", "no-std"]
Add the BlueOak-1.0.0 license I prefer to use BlueOak-1.0.0 now; It wasn’t around back in 2017. There are a number of commits in this repository not made by me, all from before Rust 1.0.0: • f1710353a039c1d5e95d15bb54effd7cab8e047f (Robert Straw; trivial: matching std enum namespacing breakage) • de091453093fb5139de71b085411d2fad1a52275 (Robert Straw; trivial: std enum namespacing breakage) • 2e37f0d1aebbd0c56acd0de7b46d14cd71d3e134 (Jonathan Reem; added AnyMap::contains, which had become obvious for Rust collection parity) • 8b30c87fe6cf514544d8bc68989631daac8aeec1 (tivek; trivial: Rust syntax change in integer literal inference) • c9d196be5f40fb0c6e53c65fa072aea60de8c3f1 (Jonathan Reem; trivial: version bump) • 330bc5aa1e4b1644a19b3751ee3b65c849447005 (Jonathan Reem; not creative and largely no longer present: introduced Cargo support, tweaked Makefile) • a9b1e31b7062e42248347805cbee662efe0eb713 (Tomas Sedovic; nigh-trivial and no longer present: Collection and Mutable trait implementations) • eecc4a4b758ae743486cfe4254cefd136f829391 (Jonathan Reem; trivial: Rust syntax change) • d51aff506409d7ffa2de275cd4e3029a88de1e2a (Jonathan Reem; trivial: rustc lint change) • 56113c63b028e7d215f1c16cf90d9c5d902df477 (Jonathan Reem; trivial: Rust syntax change) All but one of these are definitely trivial, obvious, and in the context of the project and ecosystem not creative works (⅌ copyright doctrine definition); or else no longer present. The one arguable exception is 2e37f0d1aebbd0c56acd0de7b46d14cd71d3e134, adding AnyMap::contains, since I hadn’t added a contains method; but its *definition* is trivial with only one possible implementation, and subsequent to that time I did go through and check for parity with HashMap methods, to say nothing of the code having changed shape quite a bit since then too. Therefore I’m content to consider it immaterial for relicensing.
2022-01-25 12:40:30 +11:00
license = "BlueOak-1.0.0 OR MIT OR Apache-2.0"
no_std support I’m quite pleased with how this has turned out. Given the stability-despite-instability of hashbrown (that the API surface we’re depending on hasn’t changed since 0.1.1), and the deliberate altered SemVer guarantees for it, it was very tempting to leave the hashbrown range open, `version = ">=0.1.1"` or at least `version = ">=0.1.1, <1"`, but for some reason or other I ended up deciding not to. I’m still of two minds about it, really.
2022-01-25 21:24:48 +11:00
include = ["/README.md", "/COPYING", "/CHANGELOG.md", "/src"]
[features]
default = ["std"]
std = []
[dependencies]
# The hashbrown feature, disabled by default, is exposed under different stability guarantees than the usual SemVer ones: by preference the version range will only be extended, but it may be shrunk in a MINOR release. See README.md.
hashbrown = { version = ">=0.1.1, <0.13", optional = true }
Reference in a new issue Copy permalink